NTN Rel-18

 RAN1#109-e

9.12   NTN (Non-Terrestrial Networks) enhancements

Please refer to RP-220953 for detailed scope of the WI on NR NTN enhancements. Please refer to RP-220979 for detailed scope of the WI on IoT NTN enhancements.

R1-2205577        Session notes for 9.12 (NTN (Non-Terrestrial Networks) enhancements)       Ad-Hoc Chair (Huawei)

R1-2204564         Work plan for NR NTN enhancements          THALES

9.12.1     Coverage enhancement for NR NTN

R1-2204545        Discussion on NR NTN coverage enhancement       THALES

·        Proposal 1: The following target data rates are considered for MBB and VoNR performance evaluation:

o   For VoNR,  a packet size of 344 bits every 20ms i.e. a data rate of 17.2 kbps

o   For MBB, 1 Mbit/s in the DL and 100 kbit/s in the UL.

·        Proposal 2: The satellite parameters used for the NTN coverage enhancement study are provided by the two tables in section 2.2 of this contribution. 

·        Proposal 3: The UE characteristics used for the NTN coverage enhancement study are provided by the table in section 2.3 of this contribution.

·        Proposal 4: The coverage study cases used for the NTN coverage enhancement study and targeting the smartphones UEs are provided by the table in section 2.4  of this contribution.

·        Proposal 5: The following two options should be considered for the evaluation methodology:

o   Option 1: Based on link-level simulation:

§  Obtain the required SINR for the physical channels under target scenarios and service/reliability requirements.

§  Obtain the baseline performance based on required SINR and link budget template.

§  Identify target performance and coverage bottlenecks based on target performance metric.

o   Option 2: Based on link- level and system-level simulation

§  Obtain the required SINR for the given target data rate based on link-level simulation.

§  Obtain the target performance based on system-level simulation (i.e. the 5th percentile downlink or uplink SINR value in CDF curve).

·        Proposal 6: For link level simulation, adopt the parameters for PRACH provided by the table in section 4.1

·        Proposal 7: The parameters for PUSCH and PUCCH to be used for link level simulation are given the table in section 4.2 of this contribution.

·        Proposal 8: For link level simulation, adopt the channel-specific parameters for PUSCH provided by the Table in section 4.2.1 of this contribution.

·        Proposal 9: For link level simulation, adopt the channel-specific parameters for PUCCH provided by the Table in section 4.2.2 of this contribution.

·        Proposal 10: For link level simulation, adopt the parameters for PUSCH msg3 provided by the Table in section 4.3 of this contribution.

·        Proposal 11: For link level simulation, adopt the parameters for SSB provided by the Table in section 4.4 of this contribution

·        Proposal 12: For link level simulation, adopt the parameters for PDSCH provided by the Table in section 4.5 of this contribution.

·        Proposal 13: For link level simulation, adopt the channel-specific parameters for PDSCH provided by the Table in section 4.5.1 of this contribution.

·        Proposal 14: For link level simulation, adopt the channel-specific parameters for PDCCH provided by the Table in section 4.6 of this contribution.

Decision: The document is noted.

R1-2204267        On coverage enhancement for NR NTN     Apple

·        Proposal 1: The evaluation of the NR NTN coverage performance is only on FR1.

·        Proposal 2: The evaluation of the NR NTN coverage performance has the assumptions of

o   satellite orbital: GEO, LEO-1200 and LEO-600

o   frequency: 2 GHz

o   VoIP service: 320 bits with 20 ms data arriving interval

o   Low-data rate service: 100 kbps for downlink and 50 kbps for uplink

o   link-level channel model: NTN-TDL-C

o   delay spread: 100 ns

o   channel bandwidth: 20 MHz

o   UE velocity: 3 km/h

o   shadowing: 3 dB

o   atmospheric path loss: 0.2 dB for GEO, 0.1 dB for LEO-1200 and LEO-600

o   scintillation loss: 2.2 dB

o   polarization loss: 3 dB

·        Proposal 3: The evaluation of the NR NTN coverage performance has the assumption of set-1 or set-2 satellite parameters (i.e., satellite EIRP density and G/T) as reference.

·        Proposal 4: In the evaluation of the NR NTN coverage performance, the satellite EIRP density is adjusted to satisfy ITU regulation of PFD limitation.

o   With the consideration of ITU regulation of PFD limitation, the satellite EIRP density is adjusted to 44 dBW/MHz, 20 dBW/MHz and 14 dBW/MHz in GEO, LEO-1200, LEO-600, respectively.

·        Proposal 5: In the evaluation of NR NTN coverage performance, the MIL is used to identify the bottleneck physical layer channel.

·        Proposal 6: The evaluation of the NR NTN coverage performance at least examines the physical channels of PDCCH, PDSCH, Msg 2 PDSCH, Msg 3 PUSCH, Msg 4 PDSCH and Msg 4 HARQ-ACK.

·        Proposal 7: For the evaluation assumption for each physical channel, reuse Tables A.1-2 - A.1-8 in TR 38.830 as much as possible.

Decision: The document is noted.

R1-2203588        Discussions on coverage enhancement for NR NTN              vivo

·        Proposal 1: Reuse the link budget calculation methodology used in NR Rel-16 for NTN coverage study in NR Rel-18.

·        Proposal 2: Reuse the simulation assumptions agreed in Rel-16 NR NTN study, except that at least following assumptions should be updated for link budget analysis for coverage evaluation in NR NTN in Rel-18:

o   A value of -5dBi UE TX antenna gain,

o   A wide range of elevation angles varying from 10 degrees to 90 degrees.

·        Proposal 3: Select 4.75kbps AMR data rate for voice coverage study in NTN.

·        Proposal 4: Focus on the LEO satellite to support VoIP in NTN.

·        Proposal 5: A feasible target data rate should be determined based on link budget analysis in GEO scenario.

·        Proposal 6: Send an LS to RAN2 to ask the maximum RAN protocol overhead that can be reduced for voice packet transmission in NR NTN with a reasonable complexity.

·        Proposal 7: Circular polarization enhancement on DL Tx diversity could be further studied.

·        Proposal 8: Try to reuse the coverage enhancement techniques introduced in NR Rel-17 coverage enhancement topic for coverage enhancement in NTN to minimize the work load in NTN, and study whether any NTN specific changes are needed.

Decision: The document is noted.

R1-2203159         Discussion on coverage enhancement for NR NTN     Huawei, HiSilicon

R1-2203240         Discussion on coverage enhancement for NTN           ZTE

R1-2203350         Consideration on coverage enhancement for NR NTN               Spreadtrum Communications

R1-2203389         Coverage enhancement for NR NTN              MediaTek Inc.

R1-2203669         Discussion on NTN coverage enhancement  Panasonic

R1-2203746         Considerations on improving NR NTN Coverage       Sony

R1-2203757         Discussion on coverage enhancement for NR NTN     CATT

R1-2203804         Discussion on coverage enhancement for NR-NTN    xiaomi

R1-2203844         Solutions for coverage enhancements in NR over NTN             Nokia, Nokia Shanghai Bell

R1-2203929         On coverage enhancement for NR NTN        Samsung

R1-2203946         Discussion on coverage enhancements aspects for NR NTN     NEC

R1-2204011         Discussion on coverage enhancement for NR NTN     OPPO

R1-2204079         Consideration on coverage enhancement for NR NTN               Lockheed Martin

R1-2204328         Discussion on coverage enhancement for NR NTN     CMCC

R1-2204402         Discussions on coverage enhancement for NR NTN   NTT DOCOMO, INC.

R1-2204515         Discussion on coverage enhancement for NR NTN     Lenovo

R1-2204521         Discussion on coverage enhancement for NR NTN     LG Electronics

R1-2204645         Discussions on Coverage enhancement for NR NTN  Sharp

R1-2204662         On coverage enhancement for NR NTN        Ericsson

R1-2205058         Coverage enhancements for NR NTN            Qualcomm Incorporated

[109-e-R18-NTN-01] – Shohei (NTT DOCOMO)

Email discussion on coverage enhancement for NR NTN by May 20

-        Check points: May 16, May 20

Decision: As per email decision posted on May 12^th,

Agreement

For NR NTN coverage enhancement, evaluate only handset terminals as UE type.

·        i.e., VSAT is not considered.

Decision: As per email decision posted on May 17^th,

Agreement

Coverage performance in NR NTN is evaluated according to the following steps.

·        Step 1: CNR is calculated as defined in 6.1.3.1 of TR38.821

o    For polarization loss,

-          3 dB polarization loss is assumed as baseline, and companies are encouraged to report the value and corresponding justification if other value is used

·        Step 2: Required SNR of target service is evaluated by LLS

·        Step 3: The CNR and the required SNR are compared

Agreement

Coverage performance in NR NTN is evaluated for GEO/LEO-1200/LEO-600 scenarios.

·        Note: Service type for each scenario is discussed separately

·        Note: Parameter set (Set-1/2) is discussed separately

·        Note: MEO can be evaluated optionally

R1-2205210        Summary #1 on 9.12.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO)

From May 17^th GTW session

Agreement

For evaluation of coverage performance in NR NTN,

·        It is assumed that carrier bandwidth is sufficiently large to transmit each channel.

·        Companies are encouraged to report BWP bandwidth, when necessary (e.g. for frequency hopping).

·        Note: each channel bandwidth is discussed separately.

Agreement

For VoIP, AMR 4.75 kbps (TBS of 184 bits without CRC in physical layer) with 20 ms data arriving interval is used in the evaluations.

·        Each packet is transmitted within 20 ms, if packet combining is not used.

o   Companies are encouraged to evaluate at least packet transmission without combining

o   Companies are encouraged to report how to apply packet combining, if used.

o   Note: in packet combining, two packets can be combined into a single packet at TX side

§  Companies should report the impact on E2E latency

·        VoIP is evaluated only in LEO scenario.

·        Note 1: PRB/MCS/TBS determinations are discussed separately

·        Note 2: companies should report if HARQ is used in the evaluations, and if evaluations depart from the assumption that each packet is transmitted within 20 ms

Agreement

Reuse Set-1/2 satellite parameters as in table 6.1.1.1-1/2 of TR38.821 for GEO/LEO-1200/LEO-600 and S-band, and as in table 6.1.1.1-1/2 of RP-220590 for MEO and S-band.

·        In addition, evaluations assuming relevant ITU regulatory limitations on power flux density can be reported in the study phase.

o    Companies should report which value of EIRP density is used and corresponding justification.

Decision: As per email decision posted on May 19^th,

Agreement

For link budget calculation, parameters in the following table is assumed.

Agreement

If corresponding channel (including SCS) is agreed as evaluation target channel, the following features introduced in Rel-17 Coverage enhancement WI can be applied in coverage evaluation of NR NTN.

·        For VoIP, max 20 PUSCH repetitions if SCS = 15 kHz and packet combining/HARQ are not applied; otherwise, max 32 PUSCH repetitions with consideration of the impact on E2E latency

·        For low-data rate service, max 32 PUSCH repetitions

·        TBoMS

·        Joint channel estimation (DMRS bundling)

o   Companies are encouraged to report how to apply

·        Max 16 Msg.3 PUSCH repetitions

R1-2205211        Summary #2 on 9.12.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO)

From May 20^th GTW session

Agreement

For low-data rate service, the following target data rate is assumed.

·        For DL, 3 kbps if satellite EIRP density lower than values in table 6.1.1.1-1/2 of TR38.821 for GEO/LEO-1200/LEO-600 and S-band, or values in table 6.1.1.1-1/2 of RP-220590 for MEO and S-band due to ITU regulatory limitations on power flux density is considered; otherwise, 1 Mbps

·        For UL, 3 kbps and 100 kbps

o  FFS: which data rate applies for GEO/MEO/LEO

Agreement

For NR NTN coverage enhancement, the following channels/signals can be evaluated.

·        PUSCH for VoIP

·        PUSCH for low data rate service

·        PUCCH format 1 with 2 bits

·        PUCCH format 3 with 11 bits

·        PRACH format 0

·        PRACH format 2

·        PRACH format B4

·        PUSCH Msg.3

·        PUCCH for Msg.4 HARQ-ACK

·        SSB

·        PDSCH for VoIP

·        PDSCH for low data rate service

·        PDSCH Msg.2

·        PDSCH Msg.4

·        PDCCH

·        Broadcast PDCCH (PDCCH of Msg.2)

Agreement

Evaluate coverage performance for the following UE characteristics as in Table 6.1.1.1-3 of TR38.821 with update of polarization, Tx/Rx antenna gain, and antenna type and configuration.

• X = -5 as working assumption

o   Send an LS to RAN4 to ask whether above antenna gain is valid and if invalid, appropriate value.

Agreement

For coverage performance evaluation, the following elevation angle is assumed.

·        30 deg for LEO, 12.5 deg for GEO-Set 1, 20 deg for GEO-Set 2, as in in Table 6.1.3.2-1 of TR38.821

o  Note: For GEO-Set 1, channel parameters for 10 deg is used in LLS.

·        30 deg for MEO

·        Other elevation angles can be evaluated as optional

·        Note: these values are elevation angles at the edge of the edge beam.

Agreement

For NR NTN coverage enhancement, evaluate the following cases.

R1-2205622        [Draft] LS on UE antenna gain for NR NTN coverage enhancement Moderator (NTT DOCOMO, INC.)

Decision: As per email decision posted on May 21^st, the draft LS is endorsed. Approved in R1-2205623.

Decision: As per email decision posted on May 21^st,

Agreement

For coverage performance evaluation, the following are assumed for all channels/signals

·        Channel model/Delay spread

o  Channel model as in Table 6.1.2-4 of TR38.821, assuming NTN-TDL-A (NLOS) and NTN-TDL-C (LOS)

·        Evaluation scenario

o  Rural (LOS/NLOS)

o  Sub-urban (LOS/NLOS) (optional)

·        Channel estimation: Realistic estimation

o  Companies are encouraged to report channel estimation method.

·        SCS

o  15 kHz only

·        UE speed: 3 km/h

·        Frequency drift: Not assumed

·        Frequency offset: 0.1 ppm

Agreement

For coverage evaluation of PUSCH in NR NTN, the following table is assumed.

Agreement

For coverage evaluation of PUCCH in NR NTN, the following table is assumed.

Agreement

For coverage evaluation of PRACH in NR NTN, the following table is assumed.

Agreement

For coverage evaluation of PUSCH Msg.3 in NR NTN, the following table is assumed.

Agreement

For coverage evaluation of SSB in NR NTN, the following table is assumed.

Agreement

For coverage evaluation of PDSCH in NR NTN, the following table is assumed.

Agreement

For coverage evaluation of PDCCH in NR NTN, the following table is assumed.

Final summary in R1-2205212.

9.12.2     Disabling of HARQ feedback for IoT NTN

R1-2204935        On disabling HARQ feedback for IOT-NTN           Mavenir

·        Subsequently transmitting PDSCH after k0 msec with NDI toggling can be regarded as “standard transparent” HARQ disabling, and allows the network to achieve reasonable DL throughput.

o   Although HARQ feedback is not used for determining HARQ retransmission decision, the ACK/NACK is still useful for network’s link adaptation.

·        Further studies are needed if any extra specification is necessary for HARQ disabling.

Decision: The document is noted.

R1-2203160        Discussion on disabling of HARQ feedback for IoT NTN    Huawei, HiSilicon

·        For IoT NTN with disabling HARQ mechanism, the peak rate for different scenarios can be greatly increased, and the data rate of LEOs is comparable with that of TN.

·        When repetition is taken into consideration, the stalling issues may not exist when UE is configured with 2 HARQ processes and each HARQ process schedules one TB as the NPDSCH scheduling by the second HARQ process can fill the stalling of the NPDSCH scheduling by the first HARQ process.

·        In IoT NTN, the maximum data rate can be greatly impacted in the case when large number of repetition is used for link budget improvement.

·        For repetition scenario, due to the long duration of NPDCCH and NPDSCH transmission, the performance improvement by HARQ disabling is small.

·        For the cases that can meet service requirement, power consumption can be saved due to disabling of feedback.

·        For the cases that cannot meet service requirement, with disabling HARQ mechanism, eNB can schedule new TB after 12ms from the ending of PDSCH transmission to improve the throughput.

Decision: The document is noted.

R1-2203805        Discussion on HARQ operation for IoT NTN          xiaomi

·        Proposal 1: The HARQ disabling can be supported for at least for the IoT UE that is only configured/capable of single HARQ process.

·        Proposal 2: Dynamic HARQ disabling can be supported at least for the IoT UE configured/capable of one HARQ process.

Decision: The document is noted.

R1-2204080        On disabling HARQ feedback for IoT NTN             Ericsson

·        Proposal 1: For LTE-MTC NTN, RAN1 should discuss and consider not disabling the HARQ feedback at least for LEO satellites, since non-negligible data rates in the order of hundreds of kbps are achievable using “ce-PDSCH-14HARQ-Config-r17” and “ce-PDSCH-maxTBS”.

·        Proposal 2: For NB-IoT NTN, RAN1 should discuss and consider not disabling the HARQ feedback at least for LEO satellites, since non-negligible data rates in the order of hundreds of kbps are achievable using “npdsch-16QAM-Config-r17”.

Decision: The document is noted.

R1-2203241         Discussion on disabling of HARQ feedback for IoT-NTN        ZTE

R1-2203351         Discussion on disabling of HARQ feedback for IoT NTN         Spreadtrum Communications

R1-2203390         Disabling of HARQ for IoT NTN    MediaTek Inc.

R1-2203392         Disabling of HARQ for IoT NTN    Lockheed Martin

R1-2203747         On disabling HARQ feedback for IoT-NTN Sony

R1-2203755         Disabling of HARQ feedback for IoT NTN   Nordic Semiconductor ASA

R1-2203758         HARQ feedback disabling for IoT NTN        CATT

R1-2203840         Disabling of HARQ feedback for NB-IoT/eMTC over NTN     Nokia, Nokia Shanghai Bell

R1-2203930         Disabling of HARQ feedback for IoT NTN   Samsung

R1-2203937         Disabling of HARQ feedback for IoT NTN   NEC

R1-2204012         Discussion on disabling of HARQ feedback for IoT NTN         OPPO

R1-2204268         On disabling of HARQ feedback for IoT NTN             Apple

R1-2204329         Discussion on disabling of HARQ feedback for IoT NTN         CMCC

R1-2204516         Disabling of HARQ feedback for IoT NTN   Lenovo

R1-2204646         Discussions on Disabling of HARQ feedback for IoT NTN       Sharp

R1-2205059         Disabling HARQ Feedback for IoT-NTN      Qualcomm Incorporated

[109-e-R18-NTN-02] – Zhi (Lenovo)

Email discussion on disabling of HARQ feedback for IoT NTN by May 20

-        Check points: May 16, May 20

R1-2205415         Feature lead summary #1 on disabling of HARQ feedback for IoT NTN Moderator (Lenovo)

R1-2205473        Feature lead summary #2 on disabling of HARQ feedback for IoT NTN               Moderator (Lenovo)

From May 19^th GTW session

Agreement

For IoT NTN, to configure/indicate enabling/disabling on HARQ feedback for downlink transmission, one or more of the following options can be considered:

·        Option 1: per HARQ process via UE specific RRC signaling

·        Option 2: per HARQ process via SIB signaling

·        Option 3: explicitly indicated by DCI (e.g., new field or reusing existing field)

·        Option 4: implicitly determined by existing configured/indicated parameter(s) (e.g., repetition number, TBS)

·        Option 5: per HARQ process via MAC CE

·        Other options or combinations are not excluded

Note: Option(s) for eMTC and NBIoT can be separately discussed.

Agreement

For IoT NTN, further study the potential issues due to enabling/disabling on HARQ feedback for downlink transmission

·        Issue A: SPS PDSCH

·        Issue B: (N)PDSCH/(N)PDCCH scheduling restriction

·        Issue C: HARQ feedback for scheduling multiple TB

·        Issue D: HARQ bundling for eMTC HD-FDD

·        Issue F: NPRACH capacity

·        Issue G: Serving cell/satellite change during data transfer (FFS: for eMTC and/or NB-IoT)

·        Other issues are not excluded

Note: The “Issues” in common for eMTC and NB-IoT can be separately discussed.

Final summary in R1-2205555.

9.12.3     Improved GNSS operations for IoT NTN

R1-2203391        Improved GNSS operations for IoT NTN  MediaTek Inc.

·        Proposal 1: RAN1 to study pros and cons of Options to optimize the GNSS operation in RRC_CONNECTED and UE power efficiency:

o   Option 1: “UE re-acquire GNSS position fix during RLF procedure”

o   Option 2: eNB configures a scheduling gap to re-acquire GNSS position fix

o   Option 3: “Improved scheduling operations with existing Closed Loop time adjustment”

o   Option 4: “Closed-loop frequency adjustment”

·        Proposal 2: Option 1 “UE re-acquire GNSS position fix during RLF procedure” is baseline for improved GNSS operations.

Decision: The document is noted.

R1-2203841        Enhancements for long connections in NB-IoT/eMTC over NTN      Nokia, Nokia Shanghai Bell

·        Proposal 1: GNSS measurement window in CONNECTED mode should be specified for a new GNSS measurement when GNSS position is about to outdated.

·        Proposal 2: Overhead reduction should be considered for selection of GNSS measurement window and coordination between UE and eNB.

·        Proposal 3: UE report the GNSS measurement gap should be the specified, to keep a low overhead.

·        Proposal 4: GNSS error because of UE-unaware movement should be studied and solved.

·        Proposal 5: To save power consumption and latency, keeping RRC connection and new UL synchronization after re-acquiring GNSS should be considered for long term connection, instead of going back to IDLE mode.

·        Proposal 6: How to solve the issue as GNSS expire during the long repetition for IoT should be studied.

·        Proposal 7: RAN1 to discuss how to configure multiple segment sizes for an uplink transmission.

·        Proposal 8: How to reduce the TA error for repetitions in the segment should be considered and discussed.

·        Proposal 9: How to require ephemeris and update TA during the long repetition should be studied.

·        Proposal 10: RAN1 should discuss the issue of repetition continuation between two NTN cells.

Decision: The document is noted.

R1-2203931        Improved GNSS operations for IoT NTN  Samsung

·        Proposal 1: Triggering of a new GNSS position fix can be reduced by maintaining UL synchronization via closed loop control, e.g., closed loop TA command, and closed loop pre-compensated frequency offset command.

·        Proposal 2: Acquiring a new GNSS position fix during a long connection time can be triggered by UE when there are UL data to transmit and the UL synchronization is lost.

·        Proposal 3: Acquiring a new GNSS position fix during a long connection time can be triggered by eNB when there are DL data to transmit and the UL synchronization is lost.

·        Proposal 4: For the case that a new GNSS position fix is triggered by eNB, a GNSS measurement window needs to be defined.

·        Proposal 5: Following information can be reported to eNB to assist GNSS operation:

o   Whether UE’s GNSS position is fixed or not;

o   Whether UE’s GNSS position is available in IoT application layer or not;

o   UE capability on GNSS measurement, e.g., preferred length of GNSS measurement window;

Decision: The document is noted.

R1-2205060        Improved GNSS Operations for IoT-NTN Qualcomm Incorporated

·        Proposal 1: RAN1 to consider specifying (N)PRACH-driven closed-loop time and frequency corrections, to mitigate UE power consumption on account of GNSS fixes.

·        Proposal 2: RAN1 to consider specifying (at least a subset of) NPRACH resources with increased robustness to time and frequency errors, to facilitate:

o   Accessing a cell from IDLE mode, while relaxing the requirement of an “immediately preceding” GNSS fix in all instances.

o   Closed-loop corrections (e.g., after periods of UE inactivity), thereby reducing the number of GNSS fixes required during a connection.

Decision: The document is noted.

R1-2203161         Discussion on improved GNSS operations for IoT NTN            Huawei, HiSilicon

R1-2203242         Discussion on improved GNSS operation for IoT-NTN             ZTE

R1-2203352         Discussion on improved GNSS operations for IoT NTN            Spreadtrum Communications

R1-2203759         GNSS operation issues for IoT NTN              CATT

R1-2203806         Discussion on improved GNSS operation for IoT NTN             xiaomi

R1-2203933         Improved GNSS operations for IoT NTN      Nordic Semiconductor ASA

R1-2204013         Discussion on improved GNSS operations for IoT NTN            OPPO

R1-2204269         On improved GNSS operations for IoT NTN Apple

R1-2204330         Discussion on improved GNSS operations for IoT NTN            CMCC

R1-2204517         Improved GNSS operations for IoT NTN      Lenovo

R1-2204827         On improved GNSS operation for IoT NTN  Ericsson Telecomunicazioni SpA

[109-e-R18-NTN-03] – Wen (MediaTek)

Email discussion on improved GNSS operation for IoT NTN by May 20

-        Check points: May 16, May 20

R1-2205203        Feature lead summary#1 of AI 9.12.3 on improved GNSS operations               Moderator (MediaTek)

From May 19^th GTW session

Conclusion

IoT NTN UE may need to re-acquire a valid GNSS position fix in long connection time.

·        FFS: Whether and how to update or reduce the need to update GNSS position fix in long connection time.

Agreement

Closed loop time and frequency correction, with potential enhancements, for IoT-NTN is considered to reduce the need for UE to update GNSS position fix in long connection time.

Agreement

At least the following options can be considered on GNSS measurement in connected for potential enhancements for improved GNSS operations:

·        Option 1: UE re-acquires GNSS position fix during RLF procedure

·        Option 2: UE re-acquires GNSS position fix with a new gap

Note: this does not imply that a Rel-18 IoT NTN UE is mandated to support one or both of the options.

Decision: As per email decision posted on May 20^th,

Agreement

UE reports additional GNSS assistance information and further study the detailed GNSS assistance information, including e.g. GNSS position fix measurement time

·        Note: Since RAN1 agreed that GNSS validity duration is reported by UE in Rel-17, it is already included in GNSS assistance information.

Agreement

Further study on whether there is a need for potential enhancements on the following for long connection time

·        UE triggered GNSS measurement.

·        Network triggered GNSS measurement.

Final summary in R1-2205553.

9.12.44     Other

R1-2203243         Discussion on other issues for Rel-18 NTN   ZTE

R1-2203589         Other issues for NR NTN enhancements       vivo

R1-2203760         Others issues for NR NTN CATT

R1-2203845         Other aspects related to NTN operation for Rel-18     Nokia, Nokia Shanghai Bell

R1-2203932         On TA control enhancement for NTN            Samsung

R1-2203938         Discussions on NR and IoT NTN    NEC

R1-2204672         On other aspects of NTN enhancements        Ericsson

R1-2204915         Further simulation results on coverage enhancement  Huawei, HiSilicon

 RAN1#110

9.12   NTN (Non-Terrestrial Networks) enhancements

Please refer to RP-221819 for detailed scope of the WI on NR NTN enhancements. Also refer to RP-221820 and TR38.882 for additional information on network verified UE location for NR NTN. Please refer to RP-221806 for detailed scope of the WI on IoT NTN enhancements.

R1-2208150        Session notes for 9.12 (NTN (Non-Terrestrial Networks) enhancements)       Ad-Hoc Chair (Huawei)

[110-R18-NTN] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Mohamed (Thales)

R1-2205829         Work plan for NR NTN enhancements in Rel-18        THALES

R1-2206418         Discussion on UL time and frequency synchronization enhancement for NTN               BUPT

9.12.1     Coverage enhancement for NR NTN

R1-2205826         Discussion on NR NTN coverage enhancement          THALES

R1-2205832         Coverage Enhancement for NTN    Lockheed Martin

R1-2205856         Discussion on coverage enhancement for NR NTN     Huawei, HiSilicon

R1-2206009         Discussion on coverage enhancements for NTN          Spreadtrum Communications

R1-2206012         Coverage enhancement for NR NTN              NTPU

R1-2206020         Discussion on coverage enhancement for NTN           ZTE

R1-2206063         Discussions on coverage enhancement for NR NTN   vivo

R1-2206133         Considerations on improving NR NTN Coverage       Sony

R1-2206137         Coverage enhancement for NR NTN              MediaTek Inc.

R1-2206236         Discussion on coverage enhancements aspects for NR NTN     NEC

R1-2206310         Discussion on coverage enhancement for NR NTN     OPPO

R1-2206386         Discussion on coverage enhancement for NR NTN     CATT

R1-2206423         Evaluation results for NTN coverage enhancement     Panasonic

R1-2206630         Discussion on coverage enhancement for NR-NTN    Xiaomi

R1-2206848         On coverage enhancement for NR NTN        Samsung

R1-2206859         On NTN coverage enhancement      ITL

R1-2206961         Coverage enhancement for NR NTN              ETRI

R1-2207140         Evaluation of coverage enhancements for NR over NTN           Nokia, Nokia Shanghai Bell

R1-2207255         Coverage enhancements for NR NTN            Qualcomm Incorporated

R1-2207294         Discussion on coverage enhancement for NR NTN     Lenovo

R1-2207353         Performance Evaluation on Coverage Enhancement for NR NTN           Apple

R1-2207358         Discussion on coverage enhancement for NR NTN     LG Electronics

R1-2207372         Discussion on coverage enhancement for NR NTN     Baicells

R1-2207428         Discussion on coverage enhancement for NR NTN     NTT DOCOMO, INC.

R1-2207762         On coverage enhancements for NR NTN       Ericsson (rev of R1-2207556)

R1-2207808        Summary #1 on 9.12.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO, INC.)

From Monday session

Conclusion

For Rel-18 coverage enhancement in NTN, NLOS environment is deprioritized.

Proposed working assumption

For NR-NTN coverage enhancement, parameter set-1 for LEO is prioritized for VoIP

·        parameter set-2 for LEO-600 can also be considered

For NR-NTN coverage enhancement, parameter set-1 for GEO/MEO is prioritized for low-data rate services

R1-2207809        Summary #2 on 9.12.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO, INC.)

From Thursday session

Agreement

For NR-NTN coverage enhancement, RAN1 concludes that coverage enhancements specifically for GEO and MEO are de-prioritized in Rel-18.

·        Potential enhancements for LEO can also apply to GEO and MEO

Agreement

For NR-NTN coverage enhancement in Rel-18, link budget of parameter set-1 for LEO-1200 operating at LOS is considered as the target to evaluate whether each channel/signal with the existing specification needs to be enhanced or not. The targeted performances are used to evaluate the following services:

·        VoIP using AMR 4.75 kbps.

·        Low data rate of 3 kbps.

·        Potential enhancements for deployments with parameter set-1 can also apply for deployments for parameter set-2

Observation

For PUCCH format 1 with parameter set-1 for LEO-1200 operating at LOS,

·        Five sources observed that the existing specification can meet the performance requirement.

Conclusion

RAN1 concluded that enhancement is unnecessary for PUCCH format 1 with parameter set-1 for LEO-1200 operating at LOS, assuming -5dBi UE antenna gain.

Observation

For PUCCH format 3 with parameter set-1 for LEO-1200 operating at LOS,

·        Six sources observed that the existing specification can meet the performance requirement.

·        One source observed that the existing specification cannot meet the performance requirement with at least 0.6 dB gap.

Conclusion

RAN1 concluded that enhancement is unnecessary for PUCCH format 3 with parameter set-1 for LEO-1200 operating at LOS, assuming -5dBi UE antenna gain.

Observation

For PUCCH for Msg4 HARQ-ACK with parameter set-1 for LEO-1200 operating at LOS,

·        One source observed that the existing specification can meet the performance requirement.

·        Three sources observed that the existing specification cannot meet the performance requirement with a gap of 1.8 to 6 dB.

Conclusion

RAN1 concluded that PUCCH for Msg4 HARQ-ACK should be enhanced to meet the coverage requirements for parameter set-1 for LEO-1200 operating at LOS, assuming -5dBi UE antenna gain.

Observation

For PUSCH for low data rate of 3 kbps with parameter set-1 for LEO-1200 operating at LOS,

·        Eight sources observed that the existing specification can meet the performance requirement.

Conclusion

RAN1 concluded that enhancement is unnecessary for PUSCH for low data rate of 3 kbps with parameter set-1 for LEO-1200 operating at LOS, assuming -5dBi UE antenna gain.

R1-2207810         Summary #3 on 9.12.1 Coverage enhancement for NR NTN    Moderator (NTT DOCOMO, INC.)

R1-2207811        Summary #4 on 9.12.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO, INC.)

From Friday session

Observation

For PRACH format 0 with parameter set-1 for LEO-1200 operating at LOS,

·         One source observed that the existing specification can meet the performance requirement

·         Eight sources observed that the existing specification cannot meet the performance requirement with a gap of 0.3 to 5.3 dB

For PRACH format 2 with parameter set-1 for LEO-1200 operating at LOS,

·         Ten sources observed that the existing specification can meet the performance requirement

·         Two sources observed that the existing specification cannot meet the performance requirement with a gap of 1.9 to 8.8 dB

For PRACH format B4 with parameter set-1 for LEO-1200 operating at LOS,

·         Ten sources observed that the existing specification cannot meet the performance requirement with a gap of 1.2 to 11.9 dB

Note: for the observations above, some sources used 1 Rx antenna and some sources used 2 Rx antennas at the satellite.

Observation

For PUSCH for VoIP with parameter set-1 for LEO-1200 operating at LOS,

·        Six sources observed that the existing specification can meet the performance requirement with a margin of 0 to 1.7 dB

o   One company simulated by using 20 repetitions without DMRS bundling

o   Four companies simulated by using 20 repetitions with DMRS bundling

o   One company simulated by using 32 repetitions with DMRS bundling

§  Note: this is the only result using frame combining by application layer

·        Nine sources observed that the existing specification cannot meet the performance requirement with a gap of 0.3 to 8.6 dB

o   Eight companies simulated by using 20 repetitions without DMRS bundling

o   Seven companies simulated without frequency hopping

o   One company simulated by using 16 repetitions with DMRS bundling

Note: for the observations above, some sources used 1 Rx antenna and some sources used 2 Rx antennas at the satellite.

Observation

RAN1 concluded that enhancement for PUSCH for VoIP may be needed to meet the coverage requirements for parameter set-1 for LEO-1200 operating at LOS, assuming -5dBi UE antenna gain, when DMRS bundling is not applied.

Observation

For Msg3 PUSCH with parameter set-1 for LEO-1200 operating at LOS,

·        Eight sources observed that the existing specification can meet the performance requirement

·        One source observed that the existing specification cannot meet the performance requirement with a gap of 1.5 dB.

Conclusion

RAN1 concluded that enhancement is unnecessary for Msg3 PUSCH with parameter set-1 for LEO-1200 operating at LOS, assuming -5dBi UE antenna gain.

R1-2208268         Summary #5 on 9.12.1 Coverage enhancement for NR NTN    Moderator (NTT DOCOMO, INC.)

Final summary in R1-2208269.

9.12.2     Network verified UE location for NR NTN

R1-2205827         Discussion on network verified UE location in NR NTN           THALES

R1-2205859         Discussion on network-verified UE location for NR NTN         Huawei, HiSilicon

R1-2206021         Discussion on network verified UE location for NR NTN         ZTE

R1-2206064         Discussions on Network verified UE location for NR NTN       vivo

R1-2206134         Network verified UE location for NR NTN   Sony

R1-2206138         Network verified UE location for NR NTN   MediaTek Inc.

R1-2206311         Discussion on network verified UE location for NR NTN         OPPO

R1-2206387         Considerations on network verified UE location for NR NTN   CATT

R1-2206424         Discussion on network verified UE location for NTN Panasonic

R1-2206503         On NTN NW verified UE location  Lenovo

R1-2206631         Discussion on the network verified location for NTN Xiaomi

R1-2206849         Network verified UE location for NR NTN   Samsung

R1-2206962         Discussion on network verified UE location for NTN ETRI

R1-2207141         Network verified UE positioning for NR over NTN    Nokia, Nokia Shanghai Bell

R1-2207256         Network verified UE location for NR NTN   Qualcomm Incorporated

R1-2207354         On Network Verified UE Location Apple

R1-2207359         Discussion on network verified UE location for NR NTN         LG Electronics

R1-2207429         Discussion on Network verified UE location for NR NTN        NTT DOCOMO, INC.

R1-2207682         On network verified UE location in NR NTN              Ericsson

R1-2207628         FL Summary #1: Network verified UE location for NR NTN   Moderator (THALES)

R1-2207629        FL Summary #2: Network verified UE location for NR NTN             Moderator (THALES)

From Monday session

Agreement

The following 3GPP defined RAT dependent positioning methods shall be considered as starting point for the study on Network verified UE location in case of NGSO based NTN deployment:

·        Multi-RTT

·        DL/UL-TDOA

Note-1: Other methods (e.g. AoA based) are not precluded

Note-2: RAT independent positioning methods are not under the scope of the study

Agreement

For evaluating positioning performance in NTN, the following metrics apply.

·        Horizontal accuracy:

o   Horizontal accuracy is the difference between a calculated horizontal position by the network and the actual horizontal position of a UE (for evaluation purposes)

o   At least CDFs of horizontal positioning errors are used as a performance metrics in NR positioning evaluations

o   At least the following percentiles of positioning error is analyzed 50%, 67%, 80%, 90%, 95%

R1-2207630        FL Summary #3: Network verified UE location for NR NTN             Moderator (THALES)

Agreement

·        The following parameters are assumed for the evaluation of RAT dependent positioning methods study in NTN:

Final summary in R1-2207631.

9.12.3     Disabling of HARQ feedback for IoT NTN

R1-2205831         Remaining Issues for HARQ           Lockheed Martin

R1-2205857         Discussion on disabling of HARQ feedback for IoT NTN         Huawei, HiSilicon

R1-2206010         Discussion on disabling of HARQ feedback for IoT NTN         Spreadtrum Communications

R1-2206022         Discussion on disabling of HARQ feedback for IoT-NTN        ZTE

R1-2206135         On disabling HARQ feedback for IoT-NTN Sony

R1-2206139         Disabling of HARQ for IoT NTN    MediaTek Inc.

R1-2206312         Discussion on disabling of HARQ feedback for IoT NTN         OPPO

R1-2206388         Discussion on disabling of HARQ feedback for IoT NTN         CATT

R1-2206480         Disabling of HARQ feedback for IoT NTN   NEC

R1-2206632         Discussion on HARQ operation for IoT NTN              Xiaomi

R1-2206850         Disabling of HARQ feedback for IoT NTN   Samsung

R1-2206881         Disabling of HARQ feedback for IoT NTN   Nordic Semiconductor ASA

R1-2206933         Discussion on disabling of HARQ feedback for IoT NTN         CMCC

R1-2207080         On disabling HARQ feedback for IOT-NTN Mavenir

R1-2207144         Discussions on disabling of HARQ feedback for IoT NTN       Sharp

R1-2207150         Disabling HARQ feedback in IoT-NTN        InterDigital, Inc.

R1-2207257         Disabling HARQ Feedback for IoT-NTN      Qualcomm Incorporated

R1-2207291         Disabling of HARQ feedback for NB-IoT/eMTC over NTN     Nokia, Nokia Shanghai Bell

R1-2207295         Disabling of HARQ feedback for IoT NTN   Lenovo

R1-2207355         HARQ Feedback Disabling for IoT NTN      Apple

R1-2207570         On disabling HARQ feedback for IoT NTN  Ericsson

R1-2207772         FLS#1 on disabling of HARQ feedback for IoT NTN Moderator (Lenovo)

R1-2207949        FLS#2 on disabling of HARQ feedback for IoT NTN           Moderator (Lenovo)

From Wed session

Agreement

For eMTC NTN, to configure/indicate enabling/disabling of HARQ feedback for downlink transmission, down select one or more from the following options:

·         Option 1: per HARQ process via UE specific RRC signaling.

·         Option 3: explicitly indicated by DCI (e.g., new field or reusing existing field).

·         Option 4: implicitly indicated by existing configured/indicated/combined parameter(s) in the DCI (e.g., repetition number, TBS)

·         Option 6: combinations of some options above.

Agreement

For NB-IoT NTN, to configure/indicate enabling/disabling of HARQ feedback for downlink transmission, down select one or more from the following options:

·         Option 1: per HARQ process via UE specific RRC signaling

·         Option 3: explicitly indicated by DCI (e.g., new field or reusing existing field)

·         Option 4: implicitly indicated by existing configured/indicated/combined parameter(s) in the DCI (e.g., repetition number, TBS)

·         Option 6: combinations of some options above

Agreement

For a DL HARQ process with disabled HARQ feedback in NB-IoT, at least the following UE behavior(s) can be considered:

• Option 1: UE is not expected to receive another NPDCCH carrying a DCI scheduling a NPDSCH for a given HARQ process that starts until X(ms) after the end of the reception of the last NPDSCH for that HARQ process.
• X =12
• Option 2: UE is not required to monitor NPDCCH in a period of Y(ms) from the end of reception of the last NPDSCH
• Y=12

Note: it may be different UE behaviors for different UE categories (e.g., UE with single/multiple HARQ processes).

Final summary in R1-2208011.

9.12.44     Improved GNSS operations for IoT NTN

R1-2205858         Discussion on improved GNSS operations for IoT NTN            Huawei, HiSilicon

R1-2206011         Discussion on improved GNSS operations for IoT NTN            Spreadtrum Communications

R1-2206023         Discussion on improved GNSS operation for IoT-NTN             ZTE

R1-2206140         Improved GNSS operations for IoT NTN      MediaTek Inc.

R1-2206313         Discussion on improved GNSS operations for IoT NTN            OPPO

R1-2206389         Improved GNSS operations for IoT NTN      CATT

R1-2206633         Discussion on improved GNSS operation for IoT NTN             Xiaomi

R1-2206851         Improved GNSS operations for IoT NTN      Samsung

R1-2206882         Improved GNSS operations for IoT NTN      Nordic Semiconductor ASA

R1-2206934         Discussion on improved GNSS operations for IoT NTN            CMCC

R1-2207151         On improved GNSS operation for IoT-NTN InterDigital, Inc.

R1-2207258         Improved GNSS Operations for IoT-NTN    Qualcomm Incorporated

R1-2207259         On improved GNSS operation in IoT NTN   Ericsson Limited

R1-2207292         Enhancements for long connections in NB-IoT/eMTC over NTN           Nokia, Nokia Shanghai Bell

R1-2207296         Improved GNSS operations for IoT NTN      Lenovo

R1-2207356         On Improved GNSS Operations for IoT NTN              Apple

R1-2207736        Feature lead summary#1 of AI 9.12.4 on improved GNSS operations               Moderator (MediaTek)

From Wed session

Agreement

GNSS assistance information that UE reports to eNB at least consists of:

• GNSS position fix time duration for measurement
• GNSS validity duration

Agreement

When eNB triggers UE to make GNSS measurements, UE re-acquires GNSS position fix

• FFS details of signalling
• FFS how UE reports GNSS assistance information after eNB trigger and the detailed content
• Note: further discuss whether a UE is expected to handle all eNB triggers

Final summary in R1-2207737.

 RAN1#110-bis-e

9.11   NTN (Non-Terrestrial Networks) enhancements

Please refer to RP-222654 for detailed scope of the WI on NR NTN enhancements. Also refer to RP-221820 and TR38.882 for additional information on network verified UE location for NR NTN. Please refer to RP-221806 for detailed scope of the WI on IoT NTN enhancements.

R1-2210694        Session notes for 9.11 (NTN (Non-Terrestrial Networks) enhancements)       Ad-Hoc Chair (Huawei)

R1-2210186         R18 WI NR-NTN-enh work plan at RAN1, 2 and 3    THALES

9.11.1     Coverage enhancement for NR NTN

R1-2208395         Coverage enhancement for NR NTN              MediaTek Inc.

R1-2208435         Discussion on coverage enhancement for NR NTN     Huawei, HiSilicon

R1-2208567         Discussion on coverage enhancements for NTN          Spreadtrum Communications

R1-2208662         Discussions on coverage enhancement for NR NTN   vivo

R1-2208693         Discussion on coverage enhancement for NTN           ZTE

R1-2208834         Discussion on coverage enhancement for NR NTN     OPPO

R1-2208954         Discussion on UL coverage enhancement for NR NTN             CATT

R1-2209071         On coverage enhancement for NR NTN        Intel Corporation

R1-2209114         On coverage enhancement for NR NTN        Sony

R1-2209264         Discussion on coverage enhancement for NR-NTN    xiaomi

R1-2209356         Discussion on coverage enhancement for NR NTN     CMCC

R1-2209411         Discussion on coverage enhancement for NR NTN     ETRI

R1-2209422         Discussion on coverage enhancements aspects for NR NTN     NEC

R1-2209599         On Coverage Enhancement for NR NTN       Apple

R1-2209656         On coverage enhancements for NR NTN       Ericsson

R1-2209750         On coverage enhancement for NR NTN        Samsung

R1-2209768         Discussion on coverage enhancement for NR NTN     Baicells

R1-2209796         Discussion on coverage enhancement for NR-NTN    Panasonic

R1-2209802         Discussion on coverage enhancement for NR NTN     LG Electronics

R1-2209921         Discussion on coverage enhancement for NR NTN     NTT DOCOMO, INC.

R1-2210004         Coverage enhancements for NR NTN            Qualcomm Incorporated

R1-2210023         Discussion on coverage enhancement for NR NTN     Lenovo

R1-2210049         Considerations on coverage enhancements for NR over NTN   Nokia, Nokia Shanghai Bell

[110bis-e-R18-NTN-01] – Shohei (NTT DOCOMO)

Email discussion on coverage enhancement for NR NTN by October 19

-        Check points: October 14, October 19

R1-2210344        Summary #1 on 9.11.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO, INC.)

From Oct 12th GTW session

Agreement

For PUCCH for Msg4 HARQ-ACK,

• Support PUCCH repetition
• Further discuss the specification impact for at least the following
• Procedure and signaling (e.g., cell-specific configuration, request to gNB and dynamic indication from gNB, UE capability indication before Msg4, etc.)
• Repetition factor
• Repetition slot counting for FDD
• Further study whether to enhance or support the following
• Frequency hopping
• DMRS bundling

Agreement

For PUCCH repetition for Msg4 HARQ-ACK,

• Discuss the following options of procedure to perform repetitions
• Option 1: UE always performs repetition if configured in cell-specific manner
• FFS: details of cell-specific configuration
• FFS: behavior of UE being incapable of repetition
• Option 2: UE requests repetition and is dynamically indicated to perform repetition
• FFS: details of repetition request
• FFS: details of configuration and dynamic repetition indication
• Option 3: UE indicates repetition capability and is dynamically indicated to perform repetition
• How UE indicates repetition capability before Msg4

Decision: As per email decision posted on Oct 16th,

Conclusion

For PUCCH repetition for Msg4 HARQ-ACK,

·         The existing mechanism on repetition slot counting (as in section 9.2.6 of TS 38.213) can be applied.

o    FFS: whether specification update to apply the existing mechanism to PUCCH repetition for Msg4 HARQ-ACK is needed.

R1-2210345        Summary #2 on 9.11.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO, INC.)

From Oct 18th GTW session

Agreement

For NTN-specific PUSCH DMRS bundling,

·         Discuss further the need of enhancement in consideration of at least the following:

o    Phase difference due to timing drift and/or doppler shift.

-          e.g., whether/how long a UE can meet phase continuity requirement specified as Table 6.4.2.5-1 in 38.101-1 in consideration of frequency error within ± 0.1 PPM specified in section 6.4.1 of 38.101-5 and timing error specified in Table 7.1C.2-1 of 38.133, whether RAN1 should introduce enhancement to meet the requirement and/or recommend RAN4 to update the requirement or UE should pre-compensate phase difference by UE implementation, etc.

o    An event which causes power consistency and phase continuity not to be maintained.

-          e.g., whether the new event is necessary to determine actual TDW(s) from each nominal TDW or the existing specification can work without any specification change or whether such event may not occur depending on implementations, etc.

o    Note: baseline performance for legacy UEs can include antenna switching

Decision: As per email decision posted on Oct 20th,

Agreement

For PUCCH transmission for Msg4 HARQ-ACK, supported number of transmissions are 1, 2, 4, 8.

·        Note: single PUCCH transmission is performed as in the existing specification, and/or (if supported for single PUCCH transmission) according to configuration/indication e.g., in signaling with respect to number of transmissions.

·        FFS: whether larger number of transmissions is supported

·        FFS: whether/how single PUCCH transmission can be configured and/or indicated

Final summary in R1-2210346.

9.11.2     Network verified UE location for NR NTN

R1-2208389         Discussion on network verified UE location in NR NTN           THALES

R1-2208396         Network verified UE location for NR NTN   MediaTek Inc.

R1-2208436         Discussion on network-verified UE location for NR NTN         Huawei, HiSilicon

R1-2208663         Discussions on network verified UE location for NR NTN        vivo

R1-2208694         Discussion on network verified UE location for NR NTN         ZTE

R1-2208835         Discussion on network verified UE location for NR NTN         OPPO

R1-2208955         Evaluations on network verified UE location for NR NTN        CATT

R1-2209072         On network verified UE location for NR NTN             Intel Corporation

R1-2209115         Network verified UE location for NR NTN   Sony

R1-2209265         Discussion on the network verified location xiaomi

R1-2209398         NTN NW verified UE location        Lenovo

R1-2209600         Discussion on Network Verified UE Location             Apple

R1-2209643         UE location determination during initial access in NTN            InterDigital, Inc.

R1-2209649         On network verified UE location in NR NTN              Ericsson Limited

R1-2209751         Network verified UE location for NR NTN   Samsung

R1-2209922         Discussion on Network verified UE location for NR NTN        NTT DOCOMO, INC.

R1-2210005         Network verified UE location for NR NTN   Qualcomm Incorporated

R1-2210050         Further discussion on Network Verified UE Positioning           Nokia, Nokia Shanghai Bell

R1-2210069         Discussion on network verified UE location for NTN PANASONIC

R1-2210195         Discussion on network verified UE location for NR NTN         LG Electronics

[110bis-e-R18-NTN-02] – Mohamed (THALES)

Email discussion on network verified UE location for NR NTN by October 19

-        Check points: October 14, October 19

R1-2208390        FL Summary #1: Network verified UE location for NR NTN             THALES

From Oct 12th GTW session

Agreement

Deprioritize the discussion on UE location verification during initial access.

R1-2208391         FL Summary #2: Network verified UE location for NR NTN   THALES

R1-2208392        FL Summary #3: Network verified UE location for NR NTN             THALES

From Oct 18th GTW session

Agreement

For the evaluation of time based positioning methods, further evaluation results taking into account satellite movement between TX and RX measurements should be provided.

• How this is characterised is also reported by companies

Final summary in R1-2208393.

9.11.3     Disabling of HARQ feedback for IoT NTN

R1-2208397         Disabling of HARQ for IoT NTN    MediaTek Inc.

R1-2208437         Discussion on disabling of HARQ feedback for IoT NTN         Huawei, HiSilicon

R1-2208568         Discussion on disabling of HARQ feedback for IoT NTN         Spreadtrum Communications

R1-2208695         Discussion on disabling of HARQ feedback for IoT-NTN        ZTE

R1-2208836         Discussion on disabling of HARQ feedback for IoT NTN         OPPO

R1-2208956         Discussion on disabling of HARQ feedback for IoT NTN         CATT

R1-2209157         Disabling of HARQ feedback for IoT NTN   NEC

R1-2209218         Disabling of HARQ feedback for IoT NTN   Nordic Semiconductor ASA

R1-2209245         Disabling of HARQ feedback for NB-IoT/eMTC over NTN     Nokia, Nokia Shanghai Bell

R1-2209266         Discussion on the HARQ operation for IoT NTN        xiaomi

R1-2209357         Discussion on disabling of HARQ feedback for IoT NTN         CMCC

R1-2209601         Discussion on HARQ Feedback Disabling for IoT NTN            Apple

R1-2209644         Disabling of HARQ feedback in IoT-NTN    InterDigital, Inc.

R1-2209651         On disabling HARQ feedback for IOT-NTN Mavenir

R1-2209752         Disabling of HARQ feedback for IoT NTN   Samsung

R1-2209931         Discussions on disabling of HARQ feedback for IoT NTN       Sharp

R1-2210006         Disabling HARQ Feedback for IoT-NTN      Qualcomm Incorporated

R1-2210024         Disabling of HARQ feedback for IoT NTN   Lenovo

R1-2210071         On disabling HARQ feedback for IoT NTN  Ericsson

[110bis-e-R18-NTN-03] – Zhi (Lenovo)

Email discussion on disabling of HARQ feedback for IoT NTN by October 19

-        Check points: October 14, October 19

R1-2210329        FLS#1 on disabling of HARQ feedback for IoT NTN           Moderator (Lenovo)

Presented in Oct 10th GTW session

Decision: As per email decision posted on Oct 16th,

Agreement

For a DL HARQ process with disabled HARQ feedback in NB-IoT, UE is not required to monitor NPDCCH in a period of Y=12(ms) from the end of reception of the NPDSCH.

R1-2210330        FLS#2 on disabling of HARQ feedback for IoT NTN           Moderator (Lenovo)

From Oct 17th GTW session

Agreement

For NB-IoT NTN, to configure/indicate enabling/disabling of HARQ feedback for downlink transmission, down select ONE from the following options at RAN1#111:

·         Option 6a-1: Support RRC signaling configured between Option 1 and Option 3

·         Option 6a-4: Support Option 1 by default, and support Option 3 to override default configuration for corresponding transmission

9.11.44     Improved GNSS operations for IoT NTN

R1-2208398         Improved GNSS operations for IoT NTN      MediaTek Inc.

R1-2208438         Discussion on improved GNSS operations for IoT NTN            Huawei, HiSilicon

R1-2208569         Discussion on improved GNSS operations for IoT NTN            Spreadtrum Communications

R1-2208696         Discussion on improved GNSS operation for IoT-NTN             ZTE

R1-2208837         Discussion on improved GNSS operations for IoT NTN            OPPO

R1-2208957         Improved GNSS operations for IoT NTN      CATT

R1-2209219         Improved GNSS operations for IoT NTN      Nordic Semiconductor ASA

R1-2209246         Enhancements for long connections in NB-IoT/eMTC over NTN           Nokia, Nokia Shanghai Bell

R1-2209267         Discussion on the improved GNSS operation for IoT NTN       xiaomi

R1-2209358         Discussion on improved GNSS operations for IoT NTN            CMCC

R1-2209602         On Improved GNSS Operations for IoT NTN              Apple

R1-2209645         GNSS acquisition and reporting in IoT NTN InterDigital, Inc.

R1-2209648         On improved GNSS operation in IoT NTN   Ericsson Limited

R1-2209753         Improved GNSS operations for IoT NTN      Samsung

R1-2210007         Improved GNSS Operations for IoT-NTN    Qualcomm Incorporated

R1-2210025         Improved GNSS operations for IoT NTN      Lenovo

[110bis-e-R18-NTN-04] – Wen (MediaTek)

Email discussion on improved GNSS operations for IoT NTN by October 19

-        Check points: October 14, October 19

R1-2210260        Feature lead summary#1 of AI 9.11.4 on improved GNSS operations               Moderator (MediaTek Inc.)

From Oct 10th GTW session

Agreement

·         Support eNB to at least aperiodically trigger UE to make GNSS measurement.

Decision: As per email decision posted on Oct 16th,

Agreement

·         If eNB aperiodically triggers UE to make GNSS measurement, a MAC CE is used.

R1-2210261        Feature lead summary#2 of AI 9.11.4 on improved GNSS operations               Moderator (MediaTek Inc.)

From Oct 17th GTW session

Agreement

UE reports GNSS position fix time duration for measurement at least during the initial access stage

·         which message carries this information is up to RAN2

Agreement

In connected mode, UE may report GNSS validation duration with MAC CE.

Final summary in R1-2210564.

 RAN1#111

9.11   NTN (Non-Terrestrial Networks) enhancements

Please refer to RP-222654 for detailed scope of the WI on NR NTN enhancements. Also refer to RP-221820 and TR38.882 for additional information on network verified UE location for NR NTN. Please refer to RP-221806 for detailed scope of the WI on IoT NTN enhancements.

R1-2212849        Session notes for 9.11 (NTN (Non-Terrestrial Networks) enhancements)       Ad-Hoc Chair (Huawei)

Endorsed and contents incorporated below.

[111-R18-NTN] – Mohamed (Thales)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2210953         R18 WI NR-NTN-enh work plan at RAN1, 2 and 3    THALES

From AI 5

R1-2210807        LS on RACH-less handover in NTN           RAN2, OPPO

R1-2212744        Discussion on how to reply to RAN2 LS on RACH-less handover in NTN               Moderator (OPPO)

R1-2212809        [Draft] reply LS on RACH-less handover in NTN  OPPO

From Nov 17th session

Proposal for draft reply LS:

RAN1 response:

For scenario (1)-(4), from RAN1 perspective the RACH-less handover is may be possible assuming the following notes can be satisfied, when UE UL transmission synchronization can be maintained by applying pre-compensation using the assistance information, e.g., epoch time, ephemeris, common TA, of the target cell.

Note 1: RAN1 assumes that the RAN4 UL synchronization requirement specified in Table 7.1C.2-1 of TS38.133 applies to the first UL transmission in the target cell.

Note 2: gNB is expected to provide valid assistance information of the target cell to UE.

Note 3: gNB is expected to ensure the UE can perform the UL transmission while respecting common TA and UE processing time.

2. Actions:

To RAN2:

RAN1 respectfully asks RAN2 to take the above response into account in the future work.

To RAN4:

RAN1 respectfully asks RAN4 whether RAN1’s assumption in Note 1 is correct.

R1-2212930        [Draft] reply LS on RACH-less handover in NTN  OPPO

From Nov 18h session

Agreement

For the draft reply LS:

RAN1 response:

For scenario 1, from RAN1 perspective the RACH-less handover is possible, assuming the following notes can be satisfied, when UE UL transmission synchronization can be maintained by applying pre-compensation using the assistance information, e.g., epoch time, ephemeris, common TA, of the target cell.

For scenario (2)-(4), from RAN1 perspective the RACH-less handover may be possible, assuming the following notes can be satisfied, when UE UL transmission synchronization can be maintained by applying pre-compensation using the assistance information, e.g., epoch time, ephemeris, common TA, of the target cell.

Note 1: RAN1 assumes that the RAN4 UL synchronization requirement specified in Table 7.1C.2-1 of TS38.133 applies to the first UL transmission in the target cell.

Note 2: gNB is expected to provide valid assistance information of the target cell to UE.

Note 3: gNB is expected to ensure the UE can perform the UL transmission while respecting common TA and UE processing time.

2. Actions:

To RAN2:

RAN1 respectfully asks RAN2 to take the above response into account in the future work.

To RAN4:

RAN1 respectfully asks RAN4 whether RAN1’s assumption in Note 1 is correct.

R1-2212997        [Draft] reply LS on RACH-less handover in NTN  OPPO

Decision: Response to RAN2 in R1-2212997 is endorsed. Final LS is approved in R1-2213001.

9.11.1     Coverage enhancement for NR NTN

R1-2210872         Discussion on coverage enhancement for NR NTN     Huawei, HiSilicon

R1-2211026         Discussions on coverage enhancements for NR NTN  vivo

R1-2211093         Coverage enhancement for NR NTN              MediaTek Inc.

R1-2211109         Discussion on coverage enhancement for NTN           ZTE

R1-2211115         Discussion on coverage enhancement for NR NTN     Hyundai Motor Company

R1-2211176         Further discussion on UL coverage enhancement for NR NTN CATT

R1-2211247         Discussion on coverage enhancements for NTN          Spreadtrum Communications

R1-2211328         Discussion on DMRS bundling for NR NTN NTPU

R1-2211342         Discussion on coverage enhancement for NR-NTN    xiaomi

R1-2211416         On coverage enhancement for NR NTN        Intel Corporation

R1-2211460         Discussion on coverage enhancement for NR NTN     OPPO

R1-2211567         Discussion on coverage enhancement for NR NTN     ETRI

R1-2211594         Discussion on coverage enhancement for NR-NTN    Panasonic

R1-2211626         On coverage enhancement for NR NTN        Sony

R1-2211699         Discussion on coverage enhancement for NR NTN     CMCC

R1-2211754         Coverage enhancement for NR NTN              NEC

R1-2211828         Discussion on Coverage Enhancement for NR NTN   Apple

R1-2211883         Discussion on coverage enhancement for NR NTN     Lenovo

R1-2211929         Discussion on coverage enhancement for NR NTN     LG Electronics

R1-2212002         Discussion on coverage enhancement for NR NTN     NTT DOCOMO, INC.

R1-2212064         On coverage enhancement for NR NTN        Samsung

R1-2212136         Coverage enhancements for NR NTN            Qualcomm Incorporated

R1-2212213         Discussion on coverage enhancement for NR NTN     Baicells

R1-2212325         On coverage enhancements for NR NTN       Ericsson

R1-2212401         Considerations on coverage enhancements for NR over NTN   Nokia, Nokia Shanghai Bell

R1-2212569        Summary #1 on 9.11.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO, INC.)

Presented in Nov 15th session.

R1-2212570         Summary #2 on 9.11.1 Coverage enhancement for NR NTN    Moderator (NTT DOCOMO, INC.)

R1-2212571        Summary #3 on 9.11.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO, INC.)

From Nov 17th session

Conclusion

For the study of NTN-specific PUSCH DMRS bundling, RAN1’s understanding is that Phase variation due to constant frequency error within ± 0.1 PPM specified in section 6.4.1 of 38.101-1 does not have impact on the phase continuity requirement for two adjacent slots specified as Table 6.4.2.5-1 in 38.101-1, according to annex F.9 and F.4 of 38.101-1.

R1-2212864        Summary #4 on 9.11.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO, INC.)

From Nov 18th session

Conclusion

RAN1 concluded that PUSCH DMRS bundling with sufficient TDW size should be applicable in NTN to meet the performance requirement for VoIP

·         FFS: How to determine TDW size, including UE capability.

·         Note: The above does not mean the performance requirements will be satisfied with DMRS bundling

Working assumption

For PUCCH repetition for Msg4 HARQ-ACK,

• One or more repetition factors may be configured via SIB
• If only one repetition factor is configured via SIB and if the value is one of {[1], 2, 4, 8}, UE capable of PUCCH repetition for Msg4 HARQ-ACK can perform repetition with the repetition factor
• FFS: whether UE requests repetition or indicates repetition capability
• If multiple factors from {1, 2, 4, 8} are configured via SIB, PUCCH repetition for Msg4 HARQ-ACK may be dynamically determined and indicated by gNB
• FFS: whether UE requests repetition or indicates repetition capability
• FFS: whether repetition factor is indicated by UE
• FFS: UE behavior when repetition factor is not configured via SIB
• FFS: whether one or more UE capabilities are needed for the above is for further discussion

Final summary in R1-2212865.

9.11.2     Network verified UE location for NR NTN

R1-2210873         Discussion on network-verified UE location for NR NTN         Huawei, HiSilicon

R1-2210948         Discussion on network verified UE location in NR NTN           THALES

R1-2211027         Discussions on UE location verification in NR NTN   vivo

R1-2211094         Network verified UE location for NR NTN   MediaTek Inc.

R1-2211110         Discussion on network verified UE location for NR NTN         ZTE

R1-2211177         Further evaluations on network verified UE location for NR NTN          CATT

R1-2211343         Discussion on the network verified location xiaomi

R1-2211417         On network verified UE location for NR NTN             Intel Corporation

R1-2211461         Discussion on network verified UE location for NR NTN         OPPO

R1-2211601         Discussion on Network-verified UE location for NTN               PANASONIC

R1-2211627         Network verified UE location for NR NTN   Sony

R1-2211746         NTN NW verified UE location        Lenovo

R1-2211765         On network verified UE location in NR NTN              Ericsson Limited

R1-2211829         On Network Verified UE Location Apple

R1-2211930         Discussion on network verified UE location for NR NTN         LG Electronics

R1-2212003         Discussion on Network verified UE location for NR NTN        NTT DOCOMO, INC.

R1-2212065         Network verified UE location for NR NTN   Samsung

R1-2212137         Network verified UE location for NR NTN   Qualcomm Incorporated

R1-2212402         Further discussion on Network Verified UE Positioning           Nokia, Nokia Shanghai Bell

R1-2210949        FL Summary #1: Network verified UE location for NR NTN             THALES

From Nov 15th session

Observation

For network verified UE location based on multi-RTT positioning method using Rx-Tx time difference measurements with single satellite, assuming the ambiguity of the mirror image position is resolved, if the UE reports needed to perform multi-RTT can be assumed to be trusted:

• Five sources observed that multi-RTT positioning method can meet the NTN UE location verification accuracy requirement for LEO 600km:
• Four sources observed that the positioning horizontal accuracy of less than 10km can be achieved with few seconds over-the-air latency (less or equal to 10s) with 95-percentile confidence level.
• Regarding the above observation, the following inputs were reported by companies:
• One source reported that the timing measurement error of SRS is smaller than 232 ns with 95% probability. And the timing measurement error of PRS can be smaller than 13ns and 16ns with 95% probability under the bandwidth of 8.64 MHz and 4.5 MHz, respectively. This source, reported also that  satellite’s movement  between TX and RX measurements is taken into account in the evaluation.
• One source reported that the timing measurement error is around 11ns for PRS detection with PRS bandwidth of 9.36 MHz. While for the SRS measurement, the maximum timing error is around 50ns with SRS bandwidth of 9.36 MHz. Further, this source, proposed that the RTT estimation error due to the movement of the satellite should be taken into account.
• Note: this source provided results using 2D positioning method is used.
• One source considered the maximum timing measurement error: 30ns, 50ns, 100ns, 200ns and uniform distribution of timing measurement error.
• One source reported that the timing measurement error of 95 percentile is equal to 8ns and 12.6ns for PRS and SRS respectively with an oversampling of 8. To take into account satellite movement between TX and RX measurements, for RTT calculation this source observed that the RTT between a satellite and a UE at time t0 can be approximated by the sum of the one-way delay at t0-T and the one-way delay at t0+T when T is small, e.g., less than 200 ms.
• One source observed that the positioning horizontal accuracy of less than 10km can be achieved with  180 seconds latency for earth fixed beam with 90-percentile confidence level
• This source reported that the timing measurement error of SRS and PRS can be smaller than 26.7ns and 6.1ns respectively with 95% probability under 30 degree elevation angle for LEO-600. Further, it observed that the satellite movement is taken into consideration when calculating the RTT.
• Two sources observed that multi-RTT positioning method require latency larger than 60 seconds for UE located nearby the orbital plane of a satellite during a certain time duration.

Note 1: Some companies observed that when 2D positioning method is used (e.g. when UE altitude is known to the network) better positioning latency/accuracy can be achieved compared to 3D positioning method.

R1-2210950        FL Summary #2: Network verified UE location for NR NTN             THALES

From Nov 17th session

Conclusion:

For network verification of UE location in NR NTN with single satellite in view with multi-RTT positioning:

·        From RAN1 perspective, if the UE’s Rx-Tx time difference measurements report can be assumed to be trusted, multi-RTT positioning method using Rx-Tx time difference measurements can meet the accuracy requirement of less than 10km with 90% confidence, in case of:

o   At least LEO600 based deployment

o   Earth fixed cells

o   Earth moving cell at least if UE dwell time within the cell is enough to perform at least two RTT measurements

• Note: the required over-the-air latency reported in evaluations ranged from less than 10s up to 180s

R1-2210951        FL Summary #3: Network verified UE location for NR NTN             THALES

From Nov 18th session

Observation

For network verified UE location based on DL-TDOA positioning method with single satellite:

Eight companies commented on the suitability of the method: Assuming the ambiguity of the mirror image position is resolved and if the UE reports needed to perform DL-TDOA can be assumed to be trusted:

·        Five sources observed that DL-TDOA positioning method can meet the NTN UE location verification accuracy requirement for LEO 600km without considering UE Clock drift:

o   Four sources observed that the positioning horizontal accuracy of less than 10km can be achieved with 30 seconds or less:

§  One of these 4 sources observed that horizontal positioning error is equal to 2.5km with 95% probability.

·        This source reported that the timing measurement error is around 11ns for PRS detection with PRS bandwidth of 9.36 MHz

o   Note 1: this source provided results using 2D positioning method.

§  One of these 4 sources observed that horizontal positioning error of DL-TDOA via PRS with 3 RSTDs and a latency of 24s is equal to 5.33km with 90% probability and 8.92km with 95% probability.

·        This source reported that the timing measurement error of PRS can be smaller than 13ns and 16ns with 95% probability under the bandwidth of 8.64 MHz and 4.5 MHz, respectively.

·        This source observed that existing CSI RS can be used to meet the requirement with comparable latency

§  One of these 4 sources observed that horizontal positioning accuracy for a latency of 30s with SNR of 5dB and with 90% probability is equal to 9.44km.

·        This source observed that the maximum timing measurement error that can be allowed to meet the accuracy requirement of 10km is about 80ns.

§  One of these 4 sources observed the horizontal positioning accuracy of less than 10km can be achieved for 90% of UEs with 12 seconds latency and for 95% of UEs with 20 seconds latency.           

·        The maximum time measurement error considered by this source is equal to 6ns

o   One source observed that the horizontal positioning error of DL-TDOA method can be smaller than 10 km with over 80% probability with 180 seconds latency.

§  This source reported that the timing measurement error of PRS can be smaller than 6.1ns with 95%

·        One source observed that the geometry of UE location relative to the satellite orbit will impact the positioning performance in DL-TDOA method e.g. for UE’s location at 200km away from the orbital plane, the NTN UE location verification accuracy requirement can be met and the positioning error of DL-TDOA method can be smaller than 10 km with 95% probability (for UE’s location at 200km away from the orbital plane) and a latency of 220 seconds in case of LEO600km and 342 seconds in case of LEO1200km. For UE located under the satellite orbit, NTN UE location verification accuracy requirement can be meet only with 30% probability.

o   This source considered 10 ns UE Clock drift for all time measurement window.

·        Position accuracy requirements may not be met if realistic assumption on UE clock drift is considered.

Observation

For network verified UE location based on UL-TDOA positioning method with single satellite:

Two companies commented on the suitability of the method: Assuming the ambiguity of the mirror image position is resolved and if the measurements needed to perform UL-TDOA can be assumed to be trusted:

·        One source observed that UL-TDOA cannot meet the target requirement for both earth fixed beam and earth moving beam. With 180s latency, positioning error performance that can be achieved is 34 km, CDF=90% and 13km, CDF=80%.

o   This source reported that the timing measurement error of SRS can be smaller than 26.7ns with 95% probability under 30 degree elevation angle for LEO-600 set-1, rural LOS S-band scenario.

·        One source observed that the geometry of UE location relative to the satellite orbit will impact the positioning performance in UL-TDOA method e.g. for UE’s location at 200km away from the orbital plane, the NTN UE location verification accuracy requirement can be met and the positioning error of UL-TDOA method can be smaller than 10 km with 95% probability (for UE’s location at 200km away from the orbital plane) and a latency of 220 seconds in case of LEO600km and 342 seconds in case of LEO1200km. For UE located under the satellite orbit, NTN UE location verification accuracy requirement can be meet only with 30% probability.

Conclusion

For network verification of UE location in NR NTN with single satellite in view with DL-TDOA positioning: From RAN1 perspective, if the UE’s RSTD measurements report can be assumed to be trusted, DL-TDOA positioning method can meet the accuracy requirement of less than 10km with 90% confidence, in case of:

·        At least LEO600 based deployment

·        Earth fixed cells

·        Earth moving cell at least if UE dwell time within the cell is enough to perform at least two RSTD measurements

Note 1: the above is based on evaluation results that didn’t account for UE Clock drift

Note 2: the required over-the-air latency reported in evaluations ranged from less than 20s up to 180s

Note 3: The requirements of Network verification of UE location may not be met if realistic assumption on UE clock drift is considered.

Conclusion

For network verification of UE location in NR NTN based on multi-RTT using UE RX-TX time difference report, if the UE reports needed to perform multi-RTT can be assumed to be trusted, existing multi-RTT framework may be reused with potential enhancements to adapt it to NTN context. This may include, but not limited to:

·        If justified: NTN-specific definition of UE RX-TX time difference, including as an example, potential modifications to UE Rx – Tx time difference to enable network verification of UE location without introducing any additional measurements at the UE (with respect to Rel-17 NTN)

o   The following is not precluded: the UE Rx – Tx time difference is defined as T_UE-RX – T_UE-TX, where T_UE-RX – T_UE-TX is directly derived from the timing advance T_TA applied by the UE at a given subframe.

o   Above does not imply that the relevant work is prioritized.

·        Other assistance data (e.g. ephemeris) to be transferred from gNB to the LMF.

·        If justified: Other assistance data (e.g. to resolve ambiguity on mirror position issue) to be transferred from UE to LMF

·        If justified: Adaptations enabling Rx-TX measurements for Multi-RTT involving multiple cells within the same satellite

For network verification of UE location in NR NTN based on DL-TDOA positioning, if the UE reports needed to perform DL-TDOA positioning can be assumed to be trusted, existing DL-TDOA positioning framework may be reused with potential enhancements to adapt it to NTN context.

Final summary in R1-2210952.

9.11.3     Disabling of HARQ feedback for IoT NTN

R1-2210874         Discussion on disabling of HARQ feedback for IoT NTN         Huawei, HiSilicon

R1-2210947         Considerations for Disablement of HARQ in IoT NTN              Lockheed Martin

R1-2211095         Disabling of HARQ for IoT NTN    MediaTek Inc.

R1-2211111         Discussion on disabling of HARQ feedback for IoT-NTN        ZTE

R1-2211178         Discussion on remaining issues of disabling of HARQ feedback for IoT NTN               CATT

R1-2211248         Discussion on disabling of HARQ feedback for IoT NTN         Spreadtrum Communications

R1-2211344         Discussion on the HARQ operation for IoT NTN        xiaomi

R1-2211462         Discussion on disabling of HARQ feedback for IoT NTN         OPPO

R1-2211548         Disabling of HARQ feedback for NB-IoT/eMTC over NTN     Nokia, Nokia Shanghai Bell

R1-2211700         Discussion on disabling of HARQ feedback for IoT NTN         CMCC

R1-2211734         Disabling of HARQ feedback in IoT-NTN    InterDigital, Inc.

R1-2211756         On disabling HARQ feedback for IOT-NTN Mavenir

R1-2211767         On disabling HARQ feedback for IoT NTN  Ericsson

R1-2211830         On HARQ Feedback Disabling for IoT NTN Apple

R1-2211884         Disabling of HARQ feedback for IoT NTN   Lenovo

R1-2212066         Disabling of HARQ feedback for IoT NTN   Samsung

R1-2212138         Disabling HARQ Feedback for IoT-NTN      Qualcomm Incorporated

R1-2212367         Disabling of HARQ feedback for IoT NTN   NEC

R1-2212432         Disabling of HARQ feedback for IoT NTN   Nordic Semiconductor ASA

R1-2212554        FLS#1 on disabling of HARQ feedback for IoT NTN           Moderator (Lenovo)

Presented in Nov 16th session

R1-2212555        FLS#2 on disabling of HARQ feedback for IoT NTN           Moderator (Lenovo)

From Nov 17th session

Working assumption

For NB-IoT NTN and eMTC NTN for CE Mode B, to configure/indicate enabling/disabling of HARQ feedback for downlink transmission:

• Support Option 1 by default, and support Option 3 to override default configuration for corresponding transmission
• Additional RRC signaling to enable Option 3
• If the bitmap for option 1 is not present and if option 3 is configured then the DCI directly indicates HARQ enable/disable. Option 3 can also be configured when the bitmap for option 1 is configured.
• FFS #1: Option 3 DCI-based overridden mechanism is applied to both semi-statically HARQ enabled and disabled processes or only applied to semi-statically HARQ disabled processes or only applied to semi-statically HARQ enabled processes.
• FFS #2: whether/how to support Option 3 overriding default configuration for corresponding transmission for multiple TBs scheduled by single DCI

For eMTC NTN, to configure/indicate enabling/disabling of HARQ feedback for downlink transmission, take Option 1 for CE Mode A.

9.11.44     Improved GNSS operations for IoT NTN

R1-2210875         Discussion on improved GNSS operations for IoT NTN            Huawei, HiSilicon

R1-2211096         Improved GNSS operations for IoT NTN      MediaTek Inc.

R1-2211112         Discussion on improved GNSS operation for IoT-NTN             ZTE

R1-2211179         Considerations on improved GNSS operationts  for IoT NTN   CATT

R1-2211249         Discussion on improved GNSS operations for IoT NTN            Spreadtrum Communications

R1-2211345         Discussion on the improved GNSS operation for IoT NTN       xiaomi

R1-2211463         Discussion on improved GNSS operations for IoT NTN            OPPO

R1-2211549         Enhancements for long connections in NB-IoT/eMTC over NTN           Nokia, Nokia Shanghai Bell

R1-2211701         Discussion on improved GNSS operations for IoT NTN            CMCC

R1-2211735         GNSS acquisition and reporting in IoT NTN InterDigital, Inc.

R1-2211755         On Improved GNSS Operations for IoT NTN              NEC

R1-2211764         On Improved GNSS operation in IoT NTN   Ericsson Limited

R1-2211831         On Improved GNSS Operations for IoT NTN              Apple

R1-2211885         Improved GNSS operations for IoT NTN      Lenovo

R1-2212067         Improved GNSS operations for IoT NTN      Samsung

R1-2212139         Improved GNSS Operations for IoT-NTN    Qualcomm Incorporated

R1-2212433         Improved GNSS operation for IoT NTN        Nordic Semiconductor ASA

R1-2212651        Feature lead summary#1 of AI 9.11.4 on improved GNSS operations               Moderator (MediaTek)

From Nov 16th session

Agreement

For GNSS measurement in RRC connected, if eNB aperiodically triggers connected UE to make GNSS measurement, UE can re-acquire GNSS position fix with a gap

• FFS details of gap configuration

The UE may re-acquire GNSS autonomously (when configured by the network) if UE does not receive eNB trigger to make GNSS measurement

• FFS based on configured timing

R1-2212652        Feature lead summary#2 of AI 9.11.4 on improved GNSS operations               Moderator (MediaTek)

Presented in Nov 17th session.

Final summary in R1-2212920.

 RAN1#112

9.11   NTN (Non-Terrestrial Networks) enhancements

Please refer to RP-223534 for detailed scope of the WI on NR NTN enhancements. Also refer to RP-221820 and TR38.882 for additional information on network verified UE location for NR NTN. Please refer to RP-223519 for detailed scope of the WI on IoT NTN enhancements.

R1-2302067        Session notes for 9.11 (NTN (Non-Terrestrial Networks) enhancements)       Ad-Hoc Chair (Huawei)

[112-R18-NTN] – Mohamed (Thales)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2300324         R18 WI NR-NTN-enh work plan at RAN1, 2 and 3    THALES

9.11.1     Coverage enhancement for NR NTN

R1-2300117         Discussion on coverage enhancement for NR NTN     Huawei, HiSilicon

R1-2300148         Consideration on coverage enhancement for NR NTN               Lockheed Martin

R1-2300236         Discussion on coverage enhancements for NTN          Spreadtrum Communications

R1-2300266         Discussion on coverage enhancement for NR NTN     OPPO

R1-2300378         Considerations on coverage enhancements for NR over NTN   Nokia, Nokia Shanghai Bell

R1-2300472         Discussions on coverage enhancements for NR NTN  vivo

R1-2300497         Discussion on coverage enhancements for NR NTN   NTPU, NYCU

R1-2300553         Discussion on coverage enhancement for NR-NTN    xiaomi

R1-2300601         Discussion on coverage enhancement for NR NTN     Baicells

R1-2300658         Further discussion on UL coverage enhancement for NR NTN CATT

R1-2300704         Discussion on coverage enhancement for NTN           ZTE

R1-2300765         Coverage enhancement for NR NTN              NEC

R1-2300888         On coverage enhancement for NR NTN        Sony

R1-2300902         Discussion on coverage enhancement for NR NTN     Hyundai Motor Company

R1-2300905         Discussion on coverage enhancement for NR-NTN    Panasonic

R1-2300921         Discussion on coverage enhancement for NR NTN     Lenovo

R1-2300939         On coverage enhancement for NR NTN        Intel Corporation

R1-2301021         Discussion on coverage enhancement for NR NTN     CMCC

R1-2301051         Discussion on coverage enhancement for NR NTN     ETRI

R1-2301055         Coverage enhancement for NR NTN              MediaTek Inc.

R1-2301072         Discussion on coverage enhancement for NR NTN     LG Electronics

R1-2301283         On coverage enhancement for NR NTN        Samsung

R1-2301365         On Coverage Enhancement for NR NTN       Apple

R1-2301432         Coverage enhancements for NR NTN            Qualcomm Incorporated

R1-2301512         Discussion on coverage enhancement for NR NTN     NTT DOCOMO, INC.

R1-2301548         Views on Coverage enhancement for NR NTN            Sharp

R1-2301726         On coverage enhancements for NR NTN       Ericsson

R1-2301835        Summary #1 on 9.11.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO, INC.)

From Monday session

Observation

For NTN-specific PUSCH DMRS bundling, in LEO 1200 with elevation angle 30 deg. and SCS = 15 kHz, RAN1’s understanding is the following:

·        Timing error limit (Table 7.1C.2-1 in 38.133) can be satisfied within at most 13 slots if TA pre-compensation update is not assumed.

o   FFS: whether/how to consider the initial timing error at the beginning

o   FFS: TA pre-compensation update is assumed

·        Frequency error limit (Section 6.4.1 in 38.101-5) can be satisfied over 32 slots if frequency pre-compensation update is not assumed.

·        FFS: impact of phase difference limit

R1-2301836        Summary #2 on 9.11.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO, INC.)

From Thursday session

Working assumption

For PUCCH repetition for Msg4 HARQ-ACK, discuss the following options as container of the [repetition request or capability report] indicated by UE.

• Option A: PRACH preamble and/or occasion
• FFS: whether PRACH resource partitioning is needed for indication of [repetition request  or capability report]
• FFS: whether or not indication of repetition factor is assumed
• Note: the relation with R18 NR coverage enhancements for PRACH may need to be considered in future meetings
• Option B: Higher layer signaling in Msg3 PUSCH
• FFS: which signaling is used
• Note: if higher layer signaling is preferred in RAN1, the feasibility will be asked to RAN2.
• Option C: Physical layer signaling in Msg3 PUSCH
• FFS: which signaling is used, e.g. DMRS ports

R1-2301837        Summary #3 on 9.11.1 Coverage enhancement for NR NTN              Moderator (NTT DOCOMO, INC.)

From Friday session

Agreement

For PUCCH repetition for Msg4 HARQ-ACK, discuss the following alternatives for dynamic indication of repetition factor from gNB.

• Alt 1: Field in DCI scheduling the Msg4 PDSCH
• Alt 1-1: One or two bits of the existing field
• Alt 1-1a: MCS field
• Alt 1-1b: PUCCH resource indicator field (e.g., with repetition factor configuration per PUCCH resource)
• Alt 1-1c: HARQ process number filed
• Alt 1-1d: DAI field
• Alt 1-1e: PDSCH-to-HARQ_feedback timing indicator field
• Alt 1-2: New field with one or two bits
• Alt 2: Field in DCI scheduling Msg3 PUSCH
• PUCCH repetition factor is indicated jointly with Msg3 repetition factor by using a pre-defined/configured relationship between PUCCH repetition factor and Msg3 repetition factor
• Note: it is assumed that there is impact on DCI design
• Alt 3: CRC scrambling of DCI scheduling the Msg4 PDSCH
• One or two CRC bits other than bits scrambled by TC-RNTI is used for the dynamic indication, etc.
• Alt 4: Implicit mapping between Msg4 HARQ ACK repetition factor and indication of Msg3 PUSCH repetition with no re-interpreted field / new field (i.e. no change to DCI design)

Working assumption

For PUCCH repetition for Msg4 HARQ-ACK,

• A RSRP threshold can be configured via SIB at least when the number of repetitions is configured by SIB.
• If the RSRP threshold is configured and the configured RSRP threshold is smaller than X,
• UE capable of PUCCH repetition for Msg4 HARQ-ACK transmits repetition request if measured RSRP is lower than a RSRP threshold.
• If the RSRP threshold is not configured, or if the configured RSRP threshold is X,
• UE capable of PUCCH repetition for Msg4 HARQ-ACK reports the capability of PUCCH repetition for Msg4 HARQ-ACK
• FFS: value of X (the maximum configurable value of the RSRP threshold)
• Down-select one from the following alternatives for the RSRP threshold.
• Alt A: The same RSRP threshold as R17 Msg3 repetition (i.e., rsrp-ThresholdMsg3-r17) is used.
• Alt B: New RSRP threshold is introduced.
• Note: UE incapable of PUCCH repetition for Msg4 HARQ-ACK transmits neither repetition request nor capability report

Final summary in R1-2302230.

9.11.2     Network verified UE location for NR NTN

R1-2300118         Discussion on network-verified UE location for NR NTN         Huawei, HiSilicon

R1-2300267         Discussion on network verified UE location for NR NTN         OPPO

R1-2300319         Discussion on network verified UE location in NR NTN           THALES

R1-2300320         FL Summary #1: Network verified UE location for NR NTN   THALES

R1-2300321         FL Summary #2: Network verified UE location for NR NTN   THALES

R1-2300322         FL Summary #3: Network verified UE location for NR NTN   THALES

R1-2300323         FL Summary #4: Network verified UE location for NR NTN   THALES

R1-2300379         Considerations on Network Verified UE Positioning  Nokia, Nokia Shanghai Bell

R1-2300473         Discussions on UE location verification in NR NTN   vivo

R1-2300554         Discussion on the network verified location for NR-NTN         xiaomi

R1-2300659         Discussion on Network verified UE location for NR NTN        CATT

R1-2300705         Discussion on network verified UE location for NR NTN         ZTE

R1-2300714         Discussion on Network-verified UE location for NTN               PANASONIC

R1-2300889         Network verified UE location for NR NTN   Sony

R1-2300966         On network verified UE location for NR NTN             Intel Corporation

R1-2301052         Discussion on Network verified UE location for NR NTN        ETRI

R1-2301056         Network verified UE location for NR NTN   MediaTek Inc.

R1-2301073         Discussion on network verified UE location for NR NTN         LG Electronics

R1-2301217         NTN NW verified UE location        Lenovo

R1-2301284         Network verified UE location for NR NTN   Samsung

R1-2301305         On network verified UE location in NR NTN              Ericsson Limited

R1-2301366         Discussion on Network Verified UE Location             Apple

R1-2301433         Network verified UE location for NR NTN   Qualcomm Incorporated

R1-2301513         Discussion on Network verified UE location for NR NTN        NTT DOCOMO, INC.

R1-2301653         Discussion on Network Verified Location for NR NTN             TCL Communication Ltd.

R1-2300320        FL Summary #1: Network verified UE location for NR NTN             THALES

From Monday session

Agreement

Existing DL/UL reference signals for positioning are used for supporting Network verified UE location in NTN.

FFS: Whether some enhancements on these reference signals are needed for NTN

Agreement

In NTN, for the position of the reference point for definition of gNB Rx – Tx time difference measurement, consider the following options:

·        Option 1: Onboard the satellite

·        Option 2: The uplink time synchronization reference point

·        Option 3: on the gNB

R1-2300321         FL Summary #2: Network verified UE location for NR NTN   THALES

R1-2300322         FL Summary #3: Network verified UE location for NR NTN   THALES

R1-2300323        FL Summary #4: Network verified UE location for NR NTN             THALES

From Friday session

Agreement

Select one (or more) of the following options for enhancing UE Rx-Tx time difference in NTN

• Option 1: The UE Rx – Tx time difference is defined as T_UE-RX – T_UE-TX

where:

• UE Rx-Tx time difference is defined with respect to the Rx and Tx subframe timing associated with the TRP.

o   For a Transmission Point

• T_UE-RX is the UE received timing of downlink subframe #i from this Transmission Point (TP), defined by the first detected path in time.
• T_UE-TX is the UE transmit timing of the uplink subframe corresponding to subframe #i received from the TP
• One or multiple DL RS for positioning, as instructed by higher layers, can be used to determine the start of one subframe of the first arrival path of the TP.

o   FFS: For a Transmission Point different from the serving cell (e.g. a DL-PRS-only TP)

• Option 2:
• For RTT measurement in NTN, support UE report that indicates the time difference between the arrival time of a DL RS for positioning and the transmit time of an SRS.
• FFS: details of report and the definition of UE Rx-Tx time difference   
• Option 3: The legacy R17 definition of UE Rx-Tx time difference is adopted for NTN with an offset that is determined based on one of the following options:
• Option 3-1: This offset is reported as the nearest integer value in the unit of milliseconds by rounding the time difference of transmit timing of uplink subframe #i and receive timing of downlink subframe#i
• Option 3-2: UE report the index of the subframe j that is closest in time to the subframe #i received from the TP and LMF can derive the offset
• Option 3-3: TA report which corresponds to the time difference of received timing of downlink subframe #i and transmit timing of uplink subframe#i rounding up to slot granularity.
• Option 4:
• UE Rx – Tx time difference T_UE-RX – T_UE-TX  can be directly derived from timing advance T_TA
• FFS: the granularity and the reporting range of TA.
• Note: This implies that the existing framework for Multi-RTT positioning report can be used without need to specify a new TA report.

Note: The impact of UE autonomous adjustment of TA (when applied) should be taken into account

Agreement

Select one (or more) of the following options for the enhancement of gNB Rx-Tx time difference in NTN

• Option 1: The gNB Rx – Tx time difference is defined as T_gNB-RX – T_gNB-TX

Where:

§  For a Transmission Point

• T_gNB-RX is the Transmission and Reception Point (TRP) received timing of uplink subframe #i containing SRS associated with UE, defined by the first detected path in time.
• T_gNB-TX is the TRP transmit timing of the downlink subframe corresponding to uplink subframe #i received from the UE
• Multiple SRS resources can be used to determine the start of one subframe containing SRS.

§  FFS: For a Transmission Point different from the serving cell (e.g. a DL-PRS-only TP)

• Option 2:
• For RTT measurement in NTN, support gNB report of gNB Rx-Tx time as defined in 38.215 with the following change:
• Only the SRS resource starting within a subframe can be used to determine the start of the subframe.
• Option 3:
• Keep the current gNB Rx-Tx definition, and report an offset which can covers the time duration corresponds to kmac if needed.
• Option 4:
• For RTT measurement in NTN, support gNB report that indicates the time difference between the transmit time of a DL RS for positioning and the arrival time of an SRS.

• FFS: details of report.

Note: The impact of UE autonomous adjustment of TA (when applied) should be taken into account

Agreement

Study the following options to resolve the mirror positions ambiguity for multi-RTT positioning:

·        Option 1: gNB or LMF implementation to solve the mirror error issue.

o   FFS: whether there is spec impact

·        Option 2: Reuse existing ECID method (e.g. combine UE neighbor measurements to solve the ambiguity between mirror positions), with potential enhancements

·        Option 3: NR NTN UE should report the Doppler calculated on the service link

·        Option 4: a VSAT UE should report its beam pointing in respect to satellite beam line of sight

·        Option 5: Reporting of cell coverage information (e.g. cell footprint and reference point, or antenna pattern) to the LMF

·        Option 6: Support and potentially enhance the optional Rel-17 UL-AoA measurements defined for multi-RTT positioningOther solutions are not precluded

Conclusion

Geometry relating the UE and the TRPs (satellites) affects positioning accuracy for network verified UE location based on Multi-RTT.

Final summary in R1-2302223.

9.11.3     Disabling of HARQ feedback for IoT NTN

R1-2300119         Discussion on disabling of HARQ feedback for IoT NTN         Huawei, HiSilicon

R1-2300147         Considerations for Disablement of HARQ in IoT NTN              Lockheed Martin

R1-2300237         Discussion on disabling of HARQ feedback for IoT NTN         Spreadtrum Communications

R1-2300268         Discussion on disabling of HARQ feedback for IoT NTN         OPPO

R1-2300555         Discussion on the HARQ operation for IoT NTN        xiaomi

R1-2300660         Discussion on remaining issues of disabling of HARQ feedback for IoT NTN               CATT

R1-2300706         Discussion on disabling of HARQ feedback for IoT-NTN        ZTE

R1-2300825         Disabling of HARQ feedback for IoT NTN   NEC

R1-2300890         Discussion on disabling of HARQ feedback for IoT-NTN        Sony

R1-2300922         Disabling of HARQ feedback for IoT NTN   Lenovo

R1-2301022         Discussion on disabling of HARQ feedback for IoT NTN         CMCC

R1-2301057         Disabling of HARQ for IoT NTN    MediaTek Inc.

R1-2301151         On disabling HARQ feedback for IoT NTN  Ericsson

R1-2301158         Disabling of HARQ feedback for IoT NTN   InterDigital, Inc.

R1-2301209         On disabling HARQ feedback for IOT-NTN Mavenir

R1-2301285         Disabling of HARQ feedback for IoT NTN   Samsung

R1-2301367         Discussion on HARQ Feedback Disabling for IoT NTN            Apple

R1-2301434         Disabling HARQ Feedback for IoT-NTN      Qualcomm Incorporated

R1-2301549         Views on Disabling of HARQ feedback for IoT NTN Sharp

R1-2301566         Disabling of HARQ feedback for NB-IoT/eMTC over NTN     Nokia, Nokia Shanghai Bell

R1-2301623         Disabling of HARQ feedback for IoT NTN   Nordic Semiconductor ASA

R1-2301803        FLS#1 on disabling of HARQ feedback for IoT NTN           Moderator(Lenovo)

From Tuesday session

Conclusion

For eMTC HD-FDD single TB scheduled by single DCI, UE is not expected to receive a DCI with “HARQ-ACK bundling flag” field set to 1 in case the corresponding HARQ process is configured with HARQ feedback disabled by RRC signaling.

Agreement

For a DL HARQ process with disabled HARQ feedback in eMTC, UE is not expected to receive another MPDCCH carrying a DCI scheduling a PDSCH for a given HARQ process or to receive another PDSCH without corresponding MPDCCH for the given HARQ process that starts at a BL/CE DL subframe until X=3 (ms) have passed after the end of the reception of the last PDSCH for that HARQ process.

Agreement

For HARQ feedback for eMTC SPS PDSCH, at least the following is supported: UE follows the per-process HARQ feedback enabled/disabled configuration for the associated HARQ process except for the first SPS PDSCH after activation

• for the first SPS PDSCH after activation,
• Option 1: If HARQ feedback for SPS activation is additionally enabled, ACK/NACK is reported by UE for the first SPS PDSCH after activation regardless of network configuration of enabled/disabled for this HARQ process, and follow per-process HARQ feedback enabled/disabled configuration otherwise.

Conclusion

For DCI indicating SPS PDSCH release, HARQ-ACK report is performed as legacy in eMTC, regardless of HARQ feedback enabled/disabled configuration.

Agreement

For DCI-based overridden mechanism/indication in single TB scheduled by DCI, down select one of the following alternatives based on the criteria DCI overhead, PDCCH monitoring/power consumption, HARQ timer, impact on scheduling flexibility, UE implementation complexity

• Alternative 1: applies to both semi-statically HARQ enabled and disabled processes
• Alternative 2: only applied to semi-statically HARQ disabled processes
• Alternative 3: only applied to semi-statically HARQ enabled processes

R1-2301804        FLS#2 on disabling of HARQ feedback for IoT NTN           Moderator(Lenovo)

From Thursday session

Agreement

Confirm the following working assumption with the following update:

Working assumption

For NB-IoT NTN and eMTC NTN for CE Mode B, to configure/indicate enabling/disabling of HARQ feedback for downlink transmission:

·            Support Option 1 by default, and support Option 3 to override default configuration for corresponding transmission

·          Support Option 1 in case only per-HARQ process bitmap signaling is configured

·          Support Option 3 DCI direct indication of HARQ feedback enable/disable in case only DCI solution enabling/disabling signaling is configured

·          Support Option 3 DCI indication to override Option 1 configuration for corresponding transmission in case both per-HARQ process bitmap and DCI solution enabling/disabling signaling are configured

o     Additional RRC signaling to enable Option 3

o     If the bitmap for option 1 is not present and if option 3 is configured then the DCI directly indicates HARQ enable/disable. Option 3 can also be configured when the bitmap for option 1 is configured.

o    FFS #1: Option 3 DCI-based overridden mechanism is applied to both semi-statically HARQ feedback enabled and disabled processes or only applied to semi-statically HARQ feedback disabled processes or only applied to semi-statically HARQ feedback enabled processes.

o    FFS #2: whether/how to support Option 3 overriding default Option 1 configuration for corresponding transmission for multiple TBs scheduled by single DCI

o    FFS#3：Option 3 DCI-based overridden mechanism is DCI signaling to reverse the HARQ feedback enable/disable for the corresponding transmission from per-HARQ process RRC configuration or DCI signaling to directly indicate the HARQ feedback enable/disable for the corresponding transmission regardless of per-HARQ process RRC configuration.

RAN1 strives to have a common design (in terms of DCI design, PDCCH monitoring, etc.) for “Option 3” and “Option 3 + Option 1”.

For eMTC NTN, to configure/indicate enabling/disabling of HARQ feedback for downlink transmission, take Option 1 for CE Mode A.

Agreement

For DCI-based overridden/direct indication, down select one of the following based on the criteria DCI overhead, PDCCH monitoring behavior, impact on scheduling flexibility, UE implementation complexity, etc

• Option 1: Indication by adding one field in DCI
• Option 2: Indication by reusing/reinterpreting existing field in DCI

9.11.44     Improved GNSS operations for IoT NTN

R1-2300120         Discussion on improved GNSS operations for IoT NTN            Huawei, HiSilicon

R1-2300238         Discussion on improved GNSS operations for IoT NTN            Spreadtrum Communications

R1-2300269         Discussion on improved GNSS operations for IoT NTN            OPPO

R1-2300556         Discussion on the improved GNSS operation for IoT NTN       xiaomi

R1-2300661         Considerations on improved GNSS operations for IoT NTN     CATT

R1-2300707         Discussion on improved GNSS operation for IoT-NTN             ZTE

R1-2300766         On Improved GNSS Operations for IoT NTN              NEC

R1-2300923         Improved GNSS operations for IoT NTN      Lenovo

R1-2301023         Discussion on improved GNSS operations for IoT NTN            CMCC

R1-2301058         Improved GNSS operations for IoT NTN      MediaTek Inc.

R1-2301159         Improved GNSS operations for IoT NTN      InterDigital, Inc.

R1-2301286         Improved GNSS operations for IoT NTN      Samsung

R1-2301303         On improved GNSS operation in IoT NTN   Ericsson Limited

R1-2301368         Discussion on improved GNSS operations for IoT NTN            Apple

R1-2301435         Improved GNSS Operations for IoT-NTN    Qualcomm Incorporated

R1-2301567         Enhancements for long connections in NB-IoT/eMTC over NTN           Nokia, Nokia Shanghai Bell

R1-2301624         Improved GNSS operations for IoT NTN      Nordic Semiconductor ASA

R1-2301833        Feature lead summary#1 of AI 9.11.4 on improved GNSS operations               Moderator (MediaTek)

From Tuesday session

Agreement

The following alternatives can be considered to inform eNB the success of GNSS measurement at UE side after GNSS measurement in RRC connected.

• Alt-1: The UE will report the new GNSS validity duration
• Alt-2: The reception of any UL transmission from the UE at eNB after the GNSS measurement

R1-2301834        Feature lead summary#2 of AI 9.11.4 on improved GNSS operations               Moderator (MediaTek)

From Thursday session

Agreement

On the length of GNSS measurement gap, which is aperiodically triggered by eNB, the gap duration should be equal to or larger than the latest UE reported GNSS position fix time duration.

FFS: whether the gap duration is configured by eNB, or the gap duration is equal to the latest reported GNSS position fix time duration.

Agreement

On when the GNSS measurement gap starts, which is aperiodically triggered by eNB with MAC CE, RAN1 can down select one of the following alternatives:

• Alt 1: the start time should be at n+ X, where n is the end of MAC CE receiving subframe/slot
• FFS: details of X, e.g. predefined value or configured value
• Alt 2: the start time should be based on the current GNSS validity duration with delay or without delay

Agreement

UE reports only one GNSS position fix time duration for GNSS measurement at least when moving to RRC connected state.

Agreement

At least for the case when frequency error is within frequency error requirements, study the mechanisms and conditions to allow UL transmission after original GNSS validity duration expires without GNSS re-acquisition for some duration.

• FFS: with legacy closed loop time correction or enhanced closed loop time correction
• This mechanism is enabled/configured by eNB
• FFS: whether such mechanism will be specified depends on the outcome of this study

Final summary in R1-2302120.

 RAN1#112-bis-e

9.9       NTN (Non-Terrestrial Networks) enhancements

Please refer to RP-230809 for detailed scope of the WI on NR NTN enhancements. Also refer to RP-221820 and TR38.882 for additional information on network verified UE location for NR NTN. Please refer to RP-223519 for detailed scope of the WI on IoT NTN enhancements.

R1-2304172        Session notes for 9.9 (NTN (Non-Terrestrial Networks) enhancements)         Ad-Hoc Chair (Huawei)

R1-2302406         R18 WI NR-NTN-enh work plan at RAN1, 2 and 3    THALES

9.9.1        Coverage enhancement for NR NTN

R1-2302364         Discussion on coverage enhancement for NR NTN     Huawei, HiSilicon

R1-2302433         Further considerations on coverage enhancements for NR over NTN     Nokia, Nokia Shanghai Bell

R1-2302502         Discussions on remaining issues of coverage enhancements in NR NTN               vivo

R1-2302564         Discussion on coverage enhancement for NR NTN     OPPO

R1-2302616         Discussion on coverage enhancements for NTN          Spreadtrum Communications

R1-2302719         Further discussion on UL coverage enhancement for NR NTN CATT

R1-2302738         Discussion on coverage enhancement for NR NTN     Baicells

R1-2302748         Coverage enhancement for NR NTN              NEC

R1-2302812         On coverage enhancement for NR NTN        Intel Corporation

R1-2302857         On coverage enhancement for NR NTN        Sony

R1-2302998         Discussion on coverage enhancement for NR-NTN    xiaomi

R1-2303014         On coverage enhancements for NR NTN       Ericsson

R1-2303032         Discussion on coverage enhancement for NR NTN     China Telecom

R1-2303144         On coverage enhancement for NR NTN        Samsung

R1-2303204         Discussion on coverage enhancement for NR NTN     ETRI

R1-2303250         Discussion on coverage enhancement for NR NTN     CMCC

R1-2303294         Discussion on coverage enhancement for NTN           ZTE

R1-2303351         UL coverage enhancements             MediaTek Inc.

R1-2303499         On Coverage Enhancement for NR NTN       Apple

R1-2303534         Coverage enhancements for NR NTN            Lenovo

R1-2303606         Coverage enhancements for NR NTN            Qualcomm Incorporated

R1-2303625         Discussion on coverage enhancement for NR-NTN    Panasonic

R1-2303643         Views on Coverage enhancement for NR NTN            Sharp

R1-2303725         Discussion on coverage enhancement for NR NTN     NTT DOCOMO, INC.

R1-2303748         Discussion on coverage enhancement for NR NTN     LG Electronics

[112bis-e-R18-NTN-01] – Shohei (NTT DOCOMO)

Email discussion on coverage enhancement for NR NTN by April 26th

-        Check points: April 21, April 26

R1-2303950        Summary #1 on 9.9.1 Coverage enhancement for NR NTN Moderator (NTT DOCOMO, INC.)

From April 18th GTW session

Observation

For NTN-specific PUSCH DMRS bundling,

·        In LEO 1200 with elevation angle 30 deg. and SCS = 15 kHz, RAN1’s understanding is the following:

o   Phase difference limit (Table 6.4.2.5-1 in 38.101-1) cannot be satisfied over multiple slots (for carrier bandwidth 5 MHz or larger), if the PRB allocation is not within 6 PRBs from the DC carrier, pre-compensation by UE and post-compensation by gNB are not assumed, and 70.5 (us/s) timing drift rate is assumed.

o   Note: this does not imply that UE shall be scheduled within 6 PRBs from the DC carrier.

Working assumption

For NTN-specific PUSCH DMRS bundling, to satisfy the phase difference limit without causing phase discontinuity, it is assumed that pre-compensation to keep phase rotation due to timing drift within the phase difference limit can be performed at UE side.

·        UE shall not perform TA pre-compensation update within an actual TDW if it causes phase discontinuity that may violate the phase difference limit.

o   FFS: how to determine the actual TDW

·        FFS: specification impact

·        Send an LS to RAN4

From April 20th GTW session

R1-2304093      [Draft] LS on PUSCH DMRS bundling for NR NTN coverage enhancement    Moderator (NTT DOCOMO, INC.)

Decision: The draft LS is endorsed with the following revision to the action:

ACTION: RAN1 respectfully asks RAN4 to take the above RAN1 observations and agreement working assumption into account.

Final LS is approved in R1-2304094.

R1-2303951        Summary #2 on 9.9.1 Coverage enhancement for NR NTN Moderator (NTT DOCOMO, INC.)

From April 20th GTW session

Working assumption

For PUCCH repetition for Msg4 HARQ-ACK, support Option B as container of the repetition request or capability report indicated by UE.

·         Option B: Higher layer signaling in Msg3 PUSCH

Send an LS to RAN2 to ask the feasibility of Option B, and if feasible, to specify the details of Option B.

Comeback for LS – Shohei (NTT DOCOMO)

See below draft LS in x4252.

Agreement

For NTN-specific PUSCH DMRS bundling, support Alt 2 for TDW determination.

·         Alt 2: gNB-centric TDW determination

o    Nominal TDW is determined based on gNB configuration.

o    Actual TDW is determined based on gNB configuration/indication.

o    Note: Alt 2 does not imply that spec impact of actual TDW determination is assumed for NTN.

o    FFS: details, including UE capability and assistance information reporting

Decision: As per email decision posted on April 23rd,

Agreement

For PUCCH repetition for Msg4 HARQ-ACK, support Alt 1-1 for dynamic indication of repetition factor from gNB. Further discuss which field(s) to be used.

• Alt 1: Field in DCI scheduling the Msg4 PDSCH
• Alt 1-1: One or two bits of the existing field(s)
• Alt 1-1a: MCS field
• Alt 1-1b: PUCCH resource indicator field (e.g., with repetition factor configuration per PUCCH resource)
• Alt 1-1c: HARQ process number filed
• Alt 1-1d: DAI field
• Alt 1-1e: PDSCH-to-HARQ_feedback timing indicator field

Agreement

For PUCCH repetition for Msg4 HARQ-ACK, apply frequency hopping mechanism in R15/16/17 defined for PUCCH transmission for Msg4 HARQ-ACK, in every slot.

R1-2303952         Summary #3 on 9.9.1 Coverage enhancement for NR NTN       Moderator (NTT DOCOMO, INC.)

R1-2303953        Summary #4 on 9.9.1 Coverage enhancement for NR NTN Moderator (NTT DOCOMO, INC.)

From April 26th GTW session

R1-2304252        [Draft] LS on higher layer signaling in Msg3 PUSCH for PUCCH repetition for Msg4 HARQ-ACK           Moderator (NTT DOCOMO, INC.)

Decision to send the LS at RAN1#113 to provide details of “repetition request or capability report”, and to ask the feasibility of Option B, and if feasible, to specify the details of Option B.

Agreement

For PUCCH repetition for Msg4 HARQ-ACK, candidate values of only one repetition factor configuration via SIB are {2, 4, 8}.

·        i.e., configuration of only ‘1’ is not supported.

9.9.2        Network verified UE location for NR NTN

R1-2302365         Discussion on network-verified UE location for NR NTN         Huawei, HiSilicon

R1-2302401         Discussion on network verified UE location in NR NTN           THALES

R1-2302434         Further discussion on aspects related to network verified UE location for NR over NTN       Nokia, Nokia Shanghai Bell

R1-2302503         Discussions on remaining issues of UE location verification in NR NTN              vivo

R1-2302565         Discussion on network verified UE location for NR NTN         OPPO

R1-2302720         Further discussion on Network verified UE location for NR NTN           CATT

R1-2302813         On network verified UE location for NR NTN             Intel Corporation

R1-2302858         On network verified UE location for NR NTN             Sony

R1-2302894         Discussion on Network-verified UE location for NR-NTN       PANASONIC

R1-2302999         Discussion on the network verified location for NR-NTN         xiaomi

R1-2303145         Network verified UE location for NR NTN   Samsung

R1-2303205         Discussion on Network verified UE location for NR NTN        ETRI

R1-2303269         NTN NW verified UE location        Lenovo

R1-2303295         Discussion on network verified UE location for NR NTN         ZTE

R1-2303352         Network verified UE location for NR NTN   MediaTek Inc.

R1-2303433         On Network verified UE location in NR NTN             Ericsson Limited

R1-2303500         On Network Verified UE Location Apple

R1-2303607         Network verified UE location for NR NTN   Qualcomm Incorporated

R1-2303659         Discussion on Network Verified UE Location for NR NTN      TCL Communication Ltd.

R1-2303726         Discussion on Network verified UE location for NR NTN        NTT DOCOMO, INC.

R1-2303749         Discussion on network verified UE location for NR NTN         LG Electronics

R1-2303772         Network verified UE location for Rel-18 NR NTN      Sharp

[112bis-e-R18-NTN-02] – Mohamed (THALES)

Email discussion on network verified UE location for NR NTN by April 26th

-        Check points: April 21, April 26

R1-2302402        FL Summary #1: Network verified UE location for NR NTN             THALES

Presented in April 18th GTW session.

R1-2302403        FL Summary #2: Network verified UE location for NR NTN             THALES

From April 24th GTW session

Agreement

For RTT determination in NTN, discuss further the accuracy, and reporting details of combinations of the following UE and gNB receive-transmit time difference measurements:

·       Alt-1: UE Rx-Tx time difference based on Option 3 and gNB Rx-Tx time difference as defined in TS 38.215.

o   Note 1: The signaling method of UE Rx-Tx time difference definition option 1 is not precluded if Alt1 is adopted

·       Alt-2: UE Rx-Tx time difference based on Option 2 and gNB Rx-Tx time difference as defined in TS 38.215.

o   Note 2: The LMF will use the time stamp of the PRS and the time stamp of SRS to calculate the time difference between the transmission of PRS and the reception of SRS

·       Alt-3: UE Rx-Tx time difference based on Option 2 and gNB Rx-Tx time difference based on Option 4

·       FFS: One or multiple SRS can be used in determining the arrival time

·       FFS: Additional enhancement including additional information to be reported, if justified

Note 3: The impact of UE autonomous adjustment of TA (when applied) should be taken into account

Note 4: The gNB Rx-Tx time difference option in the above alternatives may need updates accordingly based on the outcome of discussion on reference point for the gNB Rx – Tx time difference

R1-2302404        FL Summary #3: Network verified UE location for NR NTN             THALES

Presented in April 26th GTW session.

Final summary in R1-2302405.

9.9.3        Disabling of HARQ feedback for IoT NTN

R1-2302366         Discussion on disabling of HARQ feedback for IoT NTN         Huawei, HiSilicon

R1-2302566         Discussion on disabling of HARQ feedback for IoT NTN         OPPO

R1-2302617         Discussion on disabling of HARQ feedback for IoT NTN         Spreadtrum Communications

R1-2302721         Discussion on remaining issues of disabling of HARQ feedback for IoT NTN               CATT

R1-2302837         Disabling of HARQ feedback for NB-IoT/eMTC over NTN     Nokia, Nokia Shanghai Bell

R1-2302859         Discussion on disabling of HARQ feedback for IoT-NTN        Sony

R1-2303000         Discussion on the HARQ operation for IoT NTN        xiaomi

R1-2303020         On disabling HARQ feedback for IoT NTN  Ericsson

R1-2303146         Disabling of HARQ feedback for IoT NTN   Samsung

R1-2303175         Disabling of HARQ feedback for IoT NTN   Nordic Semiconductor ASA

R1-2303251         Discussion on disabling of HARQ feedback for IoT NTN         CMCC

R1-2303296         Discussion on disabling of HARQ feedback for IoT-NTN        ZTE

R1-2303357         Disabling of HARQ for IoT NTN    MediaTek Inc.

R1-2303419         On disabling HARQ feedback for IoT-NTN Mavenir

R1-2303501         On HARQ Feedback Disabling for IoT NTN Apple

R1-2303542         Disabling of HARQ feedback for IoT NTN   InterDigital, Inc.

R1-2303608         Disabling HARQ Feedback for IoT-NTN      Qualcomm Incorporated

R1-2303627         Disabling of HARQ feedback for IoT NTN   Lenovo

R1-2303642         Views on Disabling of HARQ feedback for IoT NTN Sharp

R1-2303685         Disabling of HARQ feedback for IoT NTN   NEC

[112bis-e-R18-NTN-03] – Zhi (Lenovo)

Email discussion on disabling of HARQ feedback for IoT NTN by April 26th

-        Check points: April 21, April 26

R1-2303998        FLS#1 on disabling of HARQ feedback for IoT NTN           Moderator (Lenovo)

From April 20th GTW session

Agreement

For Option 3 DCI indication:

• Option A: when both per-HARQ process bitmap and DCI solution enabling/disabling signaling are configured
• DCI-based overridden mechanism is DCI signaling to reverse the HARQ feedback enable/disable for the corresponding transmission from per-HARQ process RRC configuration
• For single TB scheduled by DCI, the DCI based overridden indication is applied to one of the following options (to be down-selected):
• Option A-1: only applied to semi-statically HARQ disabled processes
• Option A-4: applied to both semi-statically HARQ disabled and enabled processes
• FFS for multiple TBs scheduled by single DCI
• Option B: DCI-based HARQ enabling/disabling direct indication in case DCI solution enabling/disabling signaling is configured and per-HARQ process bitmap signaling is not configured (i.e. no bitmap is configured)
• DCI-based mechanism is DCI signaling to directly indicate the HARQ feedback enable/disable for the corresponding transmission
• For single TB scheduled by DCI, DCI-based direct indication is applied to the scheduled TB
• FFS for multiple TBs scheduled by single DCI

R1-2303999        FLS#2 on disabling of HARQ feedback for IoT NTN           Moderator (Lenovo)

Presented in April 24th GTW session.

Decision: As per email decision posted on April 27th,

Agreement

For single TB scheduled by DCI, for DCI-based direct indication, down select one of the following based on the criteria DCI overhead, PDCCH monitoring behavior, impact on scheduling flexibility, UE implementation complexity, etc

·        Option 1: Indication by adding one field in DCI (e.g., 1-bit)

o   Note: Other fields in DCI are the same as legacy.

·        Option 2: Indication by reusing/reinterpreting existing field in DCI

o   Option 2A: HARQ-ACK related field

§  For eMTC CE mode B, one state of “HARQ-ACK resource offset” field in DCI format 6-1B is used for indication of HARQ feedback disabled, other states are used for indication of HARQ feedback enabled and corresponding HARQ-ACK resource.

·        FFS: detailed state

§  For NBIoT, one state of “HARQ-ACK resource” field in DCI format N1 is used for indication of HARQ feedback disabled, other states are used for indication of HARQ feedback enabled and corresponding HARQ-ACK resource.

·        FFS: detailed state

o   Option 2B: MCS or repetition number field

§  Reduce 1bit of legacy MCS or repetition number field and add 1bit new field in DCI format 6-1B and N1 to indicate the HARQ feedback enabled/disabled

·        FFS: detailed for interpreting of the reduced MCS or repetition number field

o   Option 2C: HARQ-ACK related field v2

§  For eMTC CE mode B, reduce 1bit of legacy “HARQ-ACK resource offset” field and add 1bit new field in DCI format 6-1B to indicate the HARQ feedback enabled/disabled

·        FFS: detailed for interpreting of the reduced “HARQ-ACK resource offset” field

§  For NBIoT, reduce 1bit of legacy “HARQ-ACK resource” field and add 1bit new field in DCI format N1 to indicate the HARQ feedback enabled/disabled

·        FFS: detailed for interpreting of the reduced “HARQ-ACK resource” field

o   Option 2D: Other indication by reusing/reinterpreting existing field

9.9.44        Improved GNSS operations for IoT NTN

R1-2302367         Discussion on improved GNSS operations for IoT NTN            Huawei, HiSilicon

R1-2302567         Discussion on improved GNSS operations for IoT NTN            OPPO

R1-2302618         Discussion on improved GNSS operations for IoT NTN            Spreadtrum Communications

R1-2302722         Discussion on remaining issues of improved GNSS operations for IoT NTN               CATT

R1-2302749         On Improved GNSS Operations for IoT NTN              NEC

R1-2302838         Enhancements for long connections in NB-IoT/eMTC over NTN           Nokia, Nokia Shanghai Bell

R1-2303001         Discussion on the improved GNSS operation for IoT NTN       xiaomi

R1-2303147         Improved GNSS operations for IoT NTN      Samsung

R1-2303176         Improved GNSS operations for IoT NTN      Nordic Semiconductor ASA

R1-2303252         Discussion on improved GNSS operations for IoT NTN            CMCC

R1-2303297         Discussion on improved GNSS operation for IoT-NTN             ZTE

R1-2303358         Improved GNSS operations for IoT NTN      MediaTek Inc.

R1-2303432         On improved GNSS operation in IoT NTN   Ericsson Limited

R1-2303502         On improved GNSS operations for IoT NTN Apple

R1-2303543         Improved GNSS operations for IoT NTN      InterDigital, Inc.

R1-2303609         Improved GNSS Operations for IoT-NTN    Qualcomm Incorporated

R1-2303628         Improved GNSS operations for IoT NTN      Lenovo

[112bis-e-R18-NTN-04] – Wen (MediaTek)

Email discussion on improved GNSS operations for IoT NTN by April 26th

-        Check points: April 21, April 26

R1-2303911        Feature lead summary#1 of AI 9.9.4 on improved GNSS operations Moderator (MediaTek)

From April 19th GTW session

Agreement

For the GNSS measurement gap aperiodically triggered with MAC CE, the duration for the GNSS measurement gap can be configured by eNB.

·         The gap duration is equal to the latest reported GNSS position fix time duration for measurement when the duration for GNSS measurement gap is not included in the configuration by eNB.

Decision: As per email decision posted on April 23rd,

Conclusion

From RAN1 perspective, UE is not forbidden to autonomously re-acquire GNSS position fix during inactive state of Connected DRX.

·         Note: The configured DL/UL transmissions during inactive state of Connected DRX should not be impacted

·         Note: details are up to RAN2

Send an LS to RAN2 for the conclusion.

Agreement

On when the aperiodic GNSS measurement gap starts, which is aperiodically triggered by eNB with MAC CE, the start time should be at n+ X, where n is the end of MAC CE receiving subframe/slot

·        FFS: details of X, e.g. predefined value or configured value, considering HARQ feedback for the MAC CE, etc

R1-2303912        Feature lead summary#2 of AI 9.9.4 on improved GNSS operations Moderator (MediaTek)

From April 24th GTW session

R1-2304125        [Draft] LS on GNSS position fix during inactive state of Connected DRX for improved GNSS operations          Moderator (MediaTek)

Agreement

Draft LS in R1-2304125 is endorsed. Final LS is approved in R1-2304126.

Decision: As per email decision posted on April 27th,

Agreement

UE reports one GNSS position fix time duration for GNSS measurement via a N-bit field at least including [1,2] seconds as component values.

·         FFS: value of N, other component value(s) of GNSS position fix time duration (e.g. N=3, with value in [3,7,13,19,25, X] seconds, and X is FFS).

FFS: whether RAN4 input is needed.

Final summary in R1-2304073.